Just a word of warning, I believe that while supporting minutes, hours, and days is rather trivial since we have such fields on the structs and so we could just increment them, supporting weeks is trickier - are all weeks composed of 7 days or there are calendars where this is not true? Maybe se should start without weeks then? Or there will be a callback for them? Leap seconds may or may not be a concern too.
>> On 3 Jun 2020, at 08:45, José Valim <[email protected]> wrote: > > Thank you for the proposal. I believe this would be a welcome change. My only > question is if we should support them in the Calendar types or directly on > the System module. Given the System module does many conversions between time > units, supporting those there is slightly more complicated. > > Perhaps we start with support on Calendar types and then we move it to System > if necessary? This means: > > 1. Support minute and hour in Time > 2. Support week in Date > 3. Support minute, hour, day and week in NaiveDateTime > 4. Support minute, hour, day and week in DateTime > > >> On Wed, Jun 3, 2020 at 5:34 AM Parker Selbert <[email protected]> >> wrote: >> Problem >> >> Functions that convert or work with time units, i.e. >> `System.convert_time_unit/1`, `DateTime.add/3` and `Time.add/3` are limited >> to working with a subset of possible time units. The current subset of named >> units includes `:second`, `:millisecond`, `:microsecond`, and `:nanosecond`. >> It is extremely common to manipulate dates and times by larger units such as >> minutes, hours or days. Currently we have to convert any values to seconds >> and then use that to change the value, which isn't particularly explicit or >> expressive. For example, to get the date for one week from now I need to >> write: >> >> DateTime.add(DateTime.utc_now(), 7 * 24 * 60 * 60, :second) >> >> Proposal >> >> I propose the addition of larger pre-defined units to make conversion more >> expressive. Units could include some or all of the following: >> `:minute` >> `:hour` >> `:day` >> `:week` >> Some larger units such as `month` or `year` are not fixed or standard units >> and could be omitted. >> >> This enables more expressive time calculations such as "one hour from now", >> "one day from now", etc.: >> >> utc_now = DateTime.utc_now() >> DateTime.add(utc_now, 30, :minute) >> DateTime.add(utc_now, 1, :hour) >> DateTime.add(utc_now, 1, :day) >> >> In my experience it is extremely common to find module attributes or >> variables that declar a unit of time to make larger values comprehensible. >> It is much clearer to specify `1, :day` instead of `@one_day_in_seconds, >> :second` or something similar. >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/7ca22377-aadc-4e5b-a57f-ad0c52fc5ba8%40googlegroups.com. > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KTjtL-4K3-hj%2Bf%3D7sqHrkOJ52_C9VJ9u_Ekc35C_dY_A%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/FF8AE738-AF6D-4B5C-8EB9-55F86DC49D8D%40wojtekmach.pl.
