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é Valimhttps://dashbit.co/ <https://dashbit.co/>* On Wed, Jan 8, 2025 at 4:46 PM Zachary Daniel <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> > 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> 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é Valimhttps://dashbit.co/ <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. > 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. > 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. To view this discussion visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4K0q1dOWpFxNH%2BxAsdJpt_G9DA-BDGJqeYxOTgD-AuDQg%40mail.gmail.com.
