Re: [elixir-core:11980] Proposal: Add `Date.from_utc_today(duration)` or `Date.shift(:utc_today, duration)`

Wed, 08 Jan 2025 07:46:34 -0800

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)


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.



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.


--
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.

--
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.

--
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.

--
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.

Reply via email to