> but what you said makes sense on paper Thats been an issue my whole life. Works well on paper, but ….. :-)
Will work up a PR ASAP. > On 9 May 2024, at 12:54 PM, José Valim <jose.va...@dashbit.co> wrote: > > Hi Kip, please send a PR. I think this will be easier to see in code but what > you said makes sense on paper. :) > > On Thu, May 9, 2024 at 02:19 Kip <kipco...@gmail.com > <mailto:kipco...@gmail.com>> wrote: >> I'm just now implementing the new callbacks for `ex_cldr_calendars` and in >> reviewing the implementation for `Calendar.ISO` is strikes me that the whole >> implementation, except for one line (see below) depends only on other >> calendar callbacks. And therefore could be moved into the `Calendar` module >> and used as an implementation for any calendar that implements `Calendar` >> behaviour. >> >> This line >> <https://github.com/elixir-lang/elixir/blob/main/lib/elixir/lib/calendar/iso.ex#L1564> >> would need to change to use `calendar.months_in_year/1` and a few other >> calls would need to change to be calendar-referenced to. Moving the code >> might also allow centralising the options handling and exceptions - it's a >> little unusual for me to see callbacks handling the options validation >> rather than the public API. >> >> I am more than happy to submit a PR for this very small refactor (thanks to >> the very clean implementation) if this idea is considered to have merit. >> >> >> On Saturday, March 9, 2024 at 1:42:34 AM UTC+11 br...@grox.io >> <mailto:br...@grox.io> wrote: >>> The biggest question is if we consider the fields in Duration a unit or >>> not. If they are units, then the most consistent choice is to keep them >>> singular, to mirror System.time_unit and friends. >>> >>> >>> This is the API I prefer: units. IMHO, it is more important to keep >>> consistency with Elixir libraries. >>> >>> -bt >>> >>> On Thu, Mar 7, 2024 at 11:02 PM José Valim <jose....@dashbit.co <>> wrote: >>>> It is worth noting that Date and friends in Elixir require a calendar >>>> field, which is not present in Duration, and therefore Duration won't be >>>> usable as Date (and friends). >>>> >>>> The biggest question is if we consider the fields in Duration a unit or >>>> not. If they are units, then the most consistent choice is to keep them >>>> singular, to mirror System.time_unit and friends. >>>> >>>> On Fri, Mar 8, 2024 at 4:55 AM Kip Cole <kipc...@gmail.com <>> wrote: >>>>> In my head, a Date.t is semantically a duration. So it’s completely valid >>>>> to pass it as a duration to Date.shift as I see it. Which argues for >>>>> singular names. >>>>> >>>>> This conversation is a bit like “is a date a point in time or an >>>>> interval”. And the answer is yes, depending. >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 8 Mar 2024, at 14:39, Sabiwara Yukichi <sabi...@gmail.com <>> wrote: >>>>>> >>>>>> >>>>>> I'm personally leaning more towards the plural, because it feels >>>>>> semantically more correct to treat a point of time and a duration as >>>>>> separate. >>>>>> >>>>>> d.year means the same thing if d is either a date or a datetime, but for >>>>>> a duration calling it d.years emphasizes the difference. >>>>>> >>>>>> It could perhaps help catch errors as well, both for the human and the >>>>>> compiler. >>>>>> One (arguably contrived) example would be structurally typed code which >>>>>> doesn't enforce any type in particular but uses the dot access or >>>>>> partial pattern matches like %{year: ..., month: ...} in order to >>>>>> support both dates or datetimes. Passing in a duration wouldn't make >>>>>> sense semantically, having different names would make it fail properly. >>>>>> >>>>>> I also agree with other reasons mentioned, the known standard one >>>>>> especially. >>>>>> >>>>>> Le jeu. 7 mars 2024 à 16:07, 'Theo Fiedler' via elixir-lang-core >>>>>> <elixir-l...@googlegroups.com <>> a écrit : >>>>>>> Right, it would make using a Duration in combination with the `add/2-3` >>>>>>> functions much harder than it needs to be. So far all time units in >>>>>>> Elixir are singular, and I think we do gain something from consistently >>>>>>> sticking to that, regardless of the context of durations, calendar >>>>>>> types and what not. >>>>>>> >>>>>>> I've seen some libraries allowing both, singular and plural, which i >>>>>>> dont want to have anything to do with, except for mentioning it though >>>>>>> haha. >>>>>>> >>>>>>> What i currently see is: >>>>>>> >>>>>>> Reasons for plural: >>>>>>> - Known standard across various libraries and programming languages >>>>>>> - Sounds natural, to shift a date by "3 months" instead of "3 month". >>>>>>> >>>>>>> Reasons for singular: >>>>>>> - Compatible with time units already defined in Elixir (also relevant >>>>>>> for extending the use of Duration later on) >>>>>>> - Reduced cognitive load as the time units are always spelled the same >>>>>>> regardless of the context >>>>>>> >>>>>>> The reasons for singular do outweigh the reasons for plural, so unless >>>>>>> we're making some very strong points for diverging from that, let's >>>>>>> keep it singular! >>>>>>> >>>>>>> On Thursday, March 7, 2024 at 7:39:15 AM UTC+1 José Valim wrote: >>>>>>>> Compatibility with the other time units is an important point. My mind >>>>>>>> is back on singular again. :) >>>>>>>> >>>>>>>> On Thu, Mar 7, 2024 at 07:20 'Theo Fiedler' via elixir-lang-core >>>>>>>> <elixir-l...@googlegroups.com <>> wrote: >>>>>>>>> While i was strongly leaning towards singular, i understand why one >>>>>>>>> would expect plural. Given that seems to be pretty standard in wild, >>>>>>>>> i am fine changing it as well. >>>>>>>>> >>>>>>>>> What mostly put me off about was that we'd end up with `Time.add(t, >>>>>>>>> 3, :minute)` vs `Time.shift(t, minutes: 3)`, which after all, maybe >>>>>>>>> isn't too bad, as we can keep the plural keys exclusive to durations. >>>>>>>>> Another reason for going with plurals is that it _should_ make >>>>>>>>> migrating from some libraries to the standard library relatively >>>>>>>>> straight forward (with the exception of microseconds). >>>>>>>>> >>>>>>>>> On Wednesday, March 6, 2024 at 11:07:52 PM UTC+1 José Valim wrote: >>>>>>>>>> After a quick glance on other programming languages, it seems >>>>>>>>>> Python, Java, Rust, and C# all have plural names. Erlang also uses >>>>>>>>>> plural in its helper functions in the timer module. So we might want >>>>>>>>>> to follow suit. >>>>>>>>>> >>>>>>>>>> On Wed, Mar 6, 2024 at 23:03 José Valim <jose....@dashbit.co <>> >>>>>>>>>> wrote: >>>>>>>>>>> We discussed plural vs singular and settled on singular so it >>>>>>>>>>> mirrors the calendar types. Thoughts? >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 6, 2024 at 23:01 Panagiotis Nezis <pne...@gmail.com <>> >>>>>>>>>>> wrote: >>>>>>>>>>>> +1 for this, awesome work Theo. Shifting dates/timestamps is such >>>>>>>>>>>> a common operation and a standard implementation would be >>>>>>>>>>>> beneficial for everybody. >>>>>>>>>>>> >>>>>>>>>>>> PS. I would expect plural in the duration fields. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> On Wed, Mar 6, 2024 at 8:23 PM José Valim <jose....@dashbit.co <>> >>>>>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> The main argument for having it in core is: >>>>>>>>>>>>> >>>>>>>>>>>>> * It integrates directly with the Calendar behaviour >>>>>>>>>>>>> * We could provide built-in sigils in the future to create >>>>>>>>>>>>> readable durations, such as ~P[3 hours and 10 minutes] >>>>>>>>>>>>> * Postgrex, Explorer, CLDR, etc all implement their own version >>>>>>>>>>>>> of durations >>>>>>>>>>>>> >>>>>>>>>>>>> Arguments for not having it in core: it happens that all of the >>>>>>>>>>>>> arguments above can also be solved without adding Duration to >>>>>>>>>>>>> Elixir and, instead, by creating a custom library: >>>>>>>>>>>>> >>>>>>>>>>>>> * A separate library could extend the calendar behaviour with >>>>>>>>>>>>> shift_* functions >>>>>>>>>>>>> * Third-party sigils can also be provided by libraries >>>>>>>>>>>>> * Postgrex, Explorer, and CLDR could create or use a package >>>>>>>>>>>>> with a duratio type shared across them all >>>>>>>>>>>>> >>>>>>>>>>>>> I would love to hear the community thoughts. >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> On Wed, Mar 6, 2024 at 7:16 PM 'Theo Fiedler' via >>>>>>>>>>>>> elixir-lang-core <elixir-l...@googlegroups.com <>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> Preface >>>>>>>>>>>>>> >>>>>>>>>>>>>> We currently have `add/2-3` to manipulate calendar types in the >>>>>>>>>>>>>> standard library. These functions allow adding a specified >>>>>>>>>>>>>> amount of time of given unit to a date/time. The standard >>>>>>>>>>>>>> library currently misses means to apply more complex, or logical >>>>>>>>>>>>>> durations to calendar types. e.g. adding a month, a week, or one >>>>>>>>>>>>>> month and 10 days to a date. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Reasons for it >>>>>>>>>>>>>> >>>>>>>>>>>>>> While similar functionality exists in libraries, such as CLDR, >>>>>>>>>>>>>> Timex, Tox, adding this functionality to the standard library >>>>>>>>>>>>>> has already been requested and discussed at multiple occasions >>>>>>>>>>>>>> over the past years. To list a few examples: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - https://github.com/elixir-lang/elixir/pull/10199 >>>>>>>>>>>>>> - >>>>>>>>>>>>>> https://elixirforum.com/t/get-date-n-months-years-in-the-past/48346/3 >>>>>>>>>>>>>> - >>>>>>>>>>>>>> https://elixir-lang.slack.com/archives/C0HEX82NR/p1709581478427009?thread_ts=1709368588.334759&cid=C0HEX82NR >>>>>>>>>>>>>> >>>>>>>>>>>>>> Furthermore the shift behaviour in the extremely popular library >>>>>>>>>>>>>> Timex changed <https://github.com/bitwalker/timex/issues/731> in >>>>>>>>>>>>>> Elixir >= 1.14.3 which may have complicated the mostly lean and >>>>>>>>>>>>>> non-breaking language upgrade Elixir has to offer. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Elixir has a great set of modules and functions that deal with >>>>>>>>>>>>>> date and time, the APIs are consistent and `shift/2-3` should >>>>>>>>>>>>>> fit right in, solving many standard needs of various industries, >>>>>>>>>>>>>> be it for reporting, appointments, events, finance... the list >>>>>>>>>>>>>> goes on, engineers probably face the need to shift time >>>>>>>>>>>>>> logically more often than not in their careers. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Technical details >>>>>>>>>>>>>> >>>>>>>>>>>>>> Duration >>>>>>>>>>>>>> A date or time must be shifted by a duration. There is an >>>>>>>>>>>>>> ISO8601 for durations >>>>>>>>>>>>>> <https://en.wikipedia.org/wiki/ISO_8601#Durations>, which the >>>>>>>>>>>>>> initial implementation is loosely following. The structure of a >>>>>>>>>>>>>> Duration lives in its own module with its own set of functions >>>>>>>>>>>>>> to create and manipulate durations. One example of where it >>>>>>>>>>>>>> diverts from the ISO standard, is that it implements >>>>>>>>>>>>>> microseconds. Microseconds in a duration are stored in the same >>>>>>>>>>>>>> format as in the time calendar types, meaning they integrate >>>>>>>>>>>>>> well and provide consistency. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Shift >>>>>>>>>>>>>> The shift behaviour is implemented as a callback on Calendar and >>>>>>>>>>>>>> supported by all calendar types: Date, DateTime, NaiveDateTime >>>>>>>>>>>>>> and Time. Date, Time and NaiveDateTime each have their own >>>>>>>>>>>>>> implementation of a "shift", while DateTime gets converted to a >>>>>>>>>>>>>> NaiveDateTime before applying the shift, and is then rebuilt to >>>>>>>>>>>>>> a DateTime in its original timezone. `shift/2-3` also has >>>>>>>>>>>>>> guaranteed output types (which isn't a given in many libraries) >>>>>>>>>>>>>> and follows the consistent API which is established in the >>>>>>>>>>>>>> calendar modules. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Find the current state of the implementation here: >>>>>>>>>>>>>> https://github.com/elixir-lang/elixir/pull/13385 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Benchmarks >>>>>>>>>>>>>> >>>>>>>>>>>>>> There are some benchmarks + StreamData tests in the PR >>>>>>>>>>>>>> description. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Outlook >>>>>>>>>>>>>> >>>>>>>>>>>>>> After adding the Duration type and shift behaviour to the >>>>>>>>>>>>>> standard library, the following things could be explored and >>>>>>>>>>>>>> derived from the initial work: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Implementing a protocol that allows Duration to be applied to >>>>>>>>>>>>>> any data type, not just dates and times. >>>>>>>>>>>>>> A range-like data type that allows us to do recurring constructs >>>>>>>>>>>>>> on any data type. For example, Duration.interval(~D[2000-01-01], >>>>>>>>>>>>>> month: 1), when iterated, would emit {:ok, date} | {:error, >>>>>>>>>>>>>> start, duration, reason} entries >>>>>>>>>>>>>> A sigil for easy creation of durations: ~P[3 hours and 10 >>>>>>>>>>>>>> minutes] >>>>>>>>>>>>>> Making it so add/2-3 reuses the shift_* functions >>>>>>>>>>>>>> Reasons against it >>>>>>>>>>>>>> >>>>>>>>>>>>>> While I am convinced that adding `shift/2-3` to the standard >>>>>>>>>>>>>> library would be very beneficial, nothing really speaks against >>>>>>>>>>>>>> the points mentioned above to be implemented in a library >>>>>>>>>>>>>> instead. However, something as crucial and central as date/time >>>>>>>>>>>>>> manipulation should still be part of the standard library, >>>>>>>>>>>>>> negating the risk of breaking changes, inconsistent behaviour >>>>>>>>>>>>>> and outdated or too unique ergonomics which aren't widely >>>>>>>>>>>>>> applicable, unlike what should be part of the standard library. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Many thanks to @jose & @kip for the initial reviews and everyone >>>>>>>>>>>>>> in advance taking the time to read the proposal! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Looking forward to hear other peoples ideas and opinions on the >>>>>>>>>>>>>> subject! >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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 elixir-lang-co...@googlegroups.com <>. >>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/cb0ed628-3848-4de0-aa13-c0f4761e4d99n%40googlegroups.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/cb0ed628-3848-4de0-aa13-c0f4761e4d99n%40googlegroups.com?utm_medium=email&utm_source=footer>. >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 elixir-lang-co...@googlegroups.com <>. >>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BNmFsMhbkRubMjnmM8c_Amq8DgmKCJtzJ1GEuM4-sVgw%40mail.gmail.com >>>>>>>>>>>>> >>>>>>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BNmFsMhbkRubMjnmM8c_Amq8DgmKCJtzJ1GEuM4-sVgw%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 elixir-lang-co...@googlegroups.com <>. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAPxxbtjvFwnMXe134RR8wjnYk%2Bm-%2BF%2BO_79dWKk3G-bt99Ln%2Bw%40mail.gmail.com >>>>>>>>>>>> >>>>>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAPxxbtjvFwnMXe134RR8wjnYk%2Bm-%2BF%2BO_79dWKk3G-bt99Ln%2Bw%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 elixir-lang-co...@googlegroups.com <>. >>>>>>>> >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/3a82f501-cc62-409c-a653-d4b6e5943407n%40googlegroups.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/3a82f501-cc62-409c-a653-d4b6e5943407n%40googlegroups.com?utm_medium=email&utm_source=footer>. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 elixir-lang-co...@googlegroups.com <>. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/786f6323-7f47-44dc-8438-8a6fc94737afn%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/786f6323-7f47-44dc-8438-8a6fc94737afn%40googlegroups.com?utm_medium=email&utm_source=footer>. >>>>>> >>>>>> >>>>>> -- >>>>>> 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 elixir-lang-co...@googlegroups.com <>. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CANnyohYGR832XTg9SawCtat3NKxJVMu%3D7KW%3D8VJ7fTCjQro8Eg%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CANnyohYGR832XTg9SawCtat3NKxJVMu%3D7KW%3D8VJ7fTCjQro8Eg%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>>>> >>>>> >>>>> -- >>>>> 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 elixir-lang-co...@googlegroups.com <>. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/elixir-lang-core/5C8C67FE-2A5D-4375-B316-B49727955084%40gmail.com >>>>> >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/5C8C67FE-2A5D-4375-B316-B49727955084%40gmail.com?utm_medium=email&utm_source=footer>. >>>> >>>> >>>> -- >>>> 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 elixir-lang-co...@googlegroups.com <>. >>> >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4K00prM7KsJ47mcc2MwL2ttz%2BNOpHp6WUt9PEPQa2gK4A%40mail.gmail.com >>>> >>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4K00prM7KsJ47mcc2MwL2ttz%2BNOpHp6WUt9PEPQa2gK4A%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>> >> >>> >>> -- >>> >>> Regards, >>> Bruce Tate >>> CEO >>> >>> >>> <https://bowtie.mailbutler.io/tracking/hit/f8218219-d2a8-4de4-9fef-1cdde6e723f6/c7c97460-016e-45fb-a4ab-0a70318c7b97> >>> >>> Groxio, LLC. >>> 512.799.9366 <tel:(512)%20799-9366> >>> br...@grox.io <> >>> grox.io <http://grox.io/> >> >> -- >> 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 elixir-lang-core+unsubscr...@googlegroups.com >> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/ef317fb5-5b37-4bbd-9cb3-a290919468b9n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/ef317fb5-5b37-4bbd-9cb3-a290919468b9n%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- > 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 elixir-lang-core+unsubscr...@googlegroups.com > <mailto:elixir-lang-core+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JvYKuoCPBa7-sak3rUJ%2B0dsStVrEF2bZ6FXGkU6o2szQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JvYKuoCPBa7-sak3rUJ%2B0dsStVrEF2bZ6FXGkU6o2szQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/4661A5CB-C518-4769-ADD1-5C7D49BE86C9%40gmail.com.
