This overlooks part of the original proposal which included potential optimizations. I don't know what they would be, but I think the idea is that certain Datetime functions might be optimizable if they don't have to start from "any given datetime" but can know that they are starting from "now".
> On Jan 8, 2025, at 12:22 PM, Allen Madsen <allen.c.mad...@gmail.com> wrote: > > It seems like the goal is just to have a shorter way to express utc_now and > utc_today, because otherwise this code is the same: > > Date.shift(Date.utc_today(), month: 1) > Date.shift(:utc_today, month: 1) > > Two ideas come to mind besides supporting the atom, that would just give you > a Date/DateTime to use here that could be shorter. > > * Change what the sigils support ~D[utc_today]/~U[utc_now] > * Make utc_today/0 and utc_now/2 Kernel functions. > > Allen Madsen > http://www.allenmadsen.com <http://www.allenmadsen.com/> > > On Wed, Jan 8, 2025 at 11:39 AM Zach Daniel <zachary.s.dan...@gmail.com > <mailto:zachary.s.dan...@gmail.com>> wrote: >> I didn't mean that we would make a struct that people could pretend was a >> datetime and do things like call `.year` on it. I meant that if we are using >> a "magic value" we could make the "magic value" be something that can be >> expanded over time. >> >> For example, if I want to make a function that takes "a thing that can be >> passed into `DateTime.shift`", it is much easier if I can say `DateTime.t() >> | DateTime.Lazy.t()` etc. Don't we have >> similar treatment for `Regex`? Like the internals aren't meant to be pattern >> matched on/used, but it can be accepted by internal functions. >> >> If we're sure there will only ever be one such atom then I guess it makes >> sense, but if I wanted go guard against "something that DateTime accepts" it >> feels like `when is_struct(datetime, DateTime) or is_struct(datetime, >> DateTime.Lazy)` would future proof that guard, where as `when >> is_struct(datetime, DateTime) or datetime == :utc_now` wouldn't. >> >>> On Jan 8, 2025, at 11:10 AM, José Valim <jose.va...@gmail.com >>> <mailto:jose.va...@gmail.com>> wrote: >>> >>> The problem is that the struct fields are public and we can't make them >>> lazy. So if the user does `DateTime.lazy(:utc_now).year`, it won't work, >>> and if the only use of said lazy types is to pass it to these functions, we >>> might as well make it an atom specific to these functions. :) >>> >>> >>> José Valim >>> https://dashbit.co/ >>> >>> >>> On Wed, Jan 8, 2025 at 4:46 PM Zachary Daniel <zachary.s.dan...@gmail.com >>> <mailto:zachary.s.dan...@gmail.com>> wrote: >>>> DateTime.shift(DateTime.lazy(:utc_now), duration) >>>> >>>> Doesn’t have the same feel of convenience but it seems to me to be a more >>>> resilient option. >>>> >>>>> On Jan 8, 2025, at 10:44 AM, Zachary Daniel <zachary.s.dan...@gmail.com >>>>> <mailto:zachary.s.dan...@gmail.com>> wrote: >>>>> >>>>> >>>>> I’m wondering if an opaque struct may be better, representing a >>>>> computed-on-demand datetime. Like `%DateTime.Lazy{}`. Then it could grow >>>>> over time without needing to expand a set of magic atoms. >>>>> >>>>>> On Jan 8, 2025, at 10:37 AM, 'Billy Lanchantin' via elixir-lang-core >>>>>> <elixir-lang-core@googlegroups.com >>>>>> <mailto:elixir-lang-core@googlegroups.com>> wrote: >>>>>> >>>>>> >>>>>> I like the functionality and neither option seems like the obvious >>>>>> choice. I agree with José here: >>>>>> >>>>>> > 2. If we go [the dedicated function] route, we may find ourselves >>>>>> > adding other functions, such as `add_to_utc_now` and `diff_to_utc_now`. >>>>>> >>>>>> So I somewhat favor `Date.shift(:utc_today, month: 1)`. It's naturally >>>>>> extensible to other bases (like `:now`, `:utc_now`) without polluting >>>>>> the temporal modules with helpers. >>>>>> >>>>>> The downside is that the types will be more awkward. `DateTime.shift/2` >>>>>> and friends will accept either a struct or one of a set of special >>>>>> atoms. So we're stuck increasing the either size of the types or the >>>>>> number functions. >>>>>> >>>>>> --- >>>>>> >>>>>> What does the `Date.range(date, duration)` return? >>>>>> On Wednesday, January 8, 2025 at 8:02:45 AM UTC-5 José Valim wrote: >>>>>>> Another scenario where :utc_now could be used is DateTime.after?(date, >>>>>>> :utc_now) >>>>>>> >>>>>>> >>>>>>> José Valim >>>>>>> https://dashbit.co/ >>>>>>> >>>>>>> >>>>>>> On Wed, Jan 8, 2025 at 1:57 PM Jon Rowe <ma...@jonrowe.co.uk <>> wrote: >>>>>>>> I'd love either of these proposals to be a reality, I often find >>>>>>>> myself building my own helpers in tests to do this sort of thing. >>>>>>>> >>>>>>>> Initially I thought the function varient was better but if you look at >>>>>>>> it as "then we might have to add all these other functions" I found >>>>>>>> myself leaning towards allowing `:utc_now` as a placeholder in the >>>>>>>> existing api, it might be slightly more verbose but it leans towards a >>>>>>>> more compact core api overall... so that gets my +1. >>>>>>>> >>>>>>>> Cheers >>>>>>>> Jon >>>>>>>> >>>>>>>> On Wed, 8 Jan 2025, at 11:06 AM, José Valim wrote: >>>>>>>>> I'd love to see something along those lines but I can't pick a >>>>>>>>> favorite. >>>>>>>>> >>>>>>>>> 1. Supporting :utc_now in "shift" could be a welcome addition, as we >>>>>>>>> could also support it in "add" and "diff" functions. However, I'd say >>>>>>>>> it is more verbose than from_utc_today. >>>>>>>>> >>>>>>>>> 2. from_utc_now/from_utc_today is clearer but less applicable. If we >>>>>>>>> go this route, we may find ourselves adding other functions, such as >>>>>>>>> `add_to_utc_now` and `diff_to_utc_now`. >>>>>>>>> >>>>>>>>> So I would love to hear everyone's thoughts. >>>>>>>>> >>>>>>>>> "Date.range/2" with a duration is a no-brainer though and we could >>>>>>>>> add it today. >>>>>>>>> >>>>>>>>> José Valim >>>>>>>>> https://dashbit.co/ >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jan 7, 2025 at 5:43 PM Wojtek Mach <woj...@wojtekmach.pl <>> >>>>>>>>> wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I'd like to propose adding the following functions: >>>>>>>>> >>>>>>>>> - `Date.from_utc_today(duration)` >>>>>>>>> - `NaiveDateTime.from_utc_today(duration)` >>>>>>>>> - `DateTime.from_utc_today(duration)` >>>>>>>>> >>>>>>>>> For example: >>>>>>>>> >>>>>>>>> # Say, now is ~U[2025-01-07 16:22:40.003901Z] >>>>>>>>> >>>>>>>>> iex> Date.from_utc_now(month: 1, day: 1) >>>>>>>>> ~D[2025-02-08] >>>>>>>>> >>>>>>>>> iex> NaiveDateTime.from_utc_now(hour: -1) >>>>>>>>> ~N[2025-01-07 15:22:40.003901] >>>>>>>>> >>>>>>>>> iex> DateTime.from_utc_now(Duration.new!(hour: 1)) >>>>>>>>> ~U[2025-01-07 17:22:40.003901Z] >>>>>>>>> >>>>>>>>> I believe they are especially useful when writing tests and they >>>>>>>>> might give opportunity for some optimizations. >>>>>>>>> >>>>>>>>> Another idea is to instead allow passing `:utc_today` / `:utc_now` to >>>>>>>>> the existing shift/2 functions: >>>>>>>>> >>>>>>>>> iex> Date.shift(:utc_today, month: 1, day: 1) >>>>>>>>> ~D[2025-02-08] >>>>>>>>> >>>>>>>>> iex> NaiveDateTime.shift(:utc_now, hour: -1) >>>>>>>>> ~N[2025-01-07 15:22:40.003901] >>>>>>>>> >>>>>>>>> iex> DateTime.from_utc_now(:utc_now, hour: 1) >>>>>>>>> ~U[2025-01-07 17:22:40.003901Z] >>>>>>>>> >>>>>>>>> Btw and this is a related but separate conversion, I think a >>>>>>>>> `Date.range(date, duration)` would be a nice addition. And so, I >>>>>>>>> believe a `Date.range(:utc_today, month: 1)` would be a natural >>>>>>>>> extension of this. I'm not sure if supporting `Date.add(:utc_today, >>>>>>>>> 1)` and similar is worth it, perhaps just for consistency. >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 visit >>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/2851ea28-d20e-4e8d-b957-38a582f7fa39n%40googlegroups.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/2851ea28-d20e-4e8d-b957-38a582f7fa39n%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 visit >>>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L9iSWc7zD8v_%2BqNhsOhx10atYksuPO5gbGCMvvz88sPA%40mail.gmail.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L9iSWc7zD8v_%2BqNhsOhx10atYksuPO5gbGCMvvz88sPA%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 visit >>>>>>>> https://groups.google.com/d/msgid/elixir-lang-core/3952efd8-06a4-4855-9277-8208b5c8068f%40app.fastmail.com >>>>>>>> >>>>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/3952efd8-06a4-4855-9277-8208b5c8068f%40app.fastmail.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 visit >>>>>> https://groups.google.com/d/msgid/elixir-lang-core/d1c3407a-5c4c-4978-a813-43eaf9711554n%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/d1c3407a-5c4c-4978-a813-43eaf9711554n%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 visit >>>> https://groups.google.com/d/msgid/elixir-lang-core/CF7D089E-DBB9-432A-B15D-4EB5DFB046DB%40gmail.com >>>> >>>> <https://groups.google.com/d/msgid/elixir-lang-core/CF7D089E-DBB9-432A-B15D-4EB5DFB046DB%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-core+unsubscr...@googlegroups.com >>> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4K0q1dOWpFxNH%2BxAsdJpt_G9DA-BDGJqeYxOTgD-AuDQg%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4K0q1dOWpFxNH%2BxAsdJpt_G9DA-BDGJqeYxOTgD-AuDQg%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 >> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>. >> To view this discussion visit >> https://groups.google.com/d/msgid/elixir-lang-core/7390B51F-96B5-44C3-8896-85B171EFB4C7%40gmail.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/7390B51F-96B5-44C3-8896-85B171EFB4C7%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-core+unsubscr...@googlegroups.com > <mailto:elixir-lang-core+unsubscr...@googlegroups.com>. > To view this discussion visit > https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3CuyeAjpoTqA44X%2B97wgfZOFbF8Q%3DvoA6uMGrut-U_RdyA%40mail.gmail.com > > <https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3CuyeAjpoTqA44X%2B97wgfZOFbF8Q%3DvoA6uMGrut-U_RdyA%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 visit https://groups.google.com/d/msgid/elixir-lang-core/3725EBE6-E269-42C8-B787-C8D8FDFF63FC%40gmail.com.
