Personally leaning towards option 1) just to avoid the urge of adding more
and more convenience to the date/time modules. Most of what is proposed can
already be achieved with "just" one additional function call. Once
introduced would we want to support this in all applicable functions, e.g.
treating :utc_today as Date.utc_today/1 everywhere? If this works in
shift/2 and add/2, why shouldn't it work in diff/2 or beginning_of_month/1.
This is the only thing that makes me hesitant of adding this, since imho,
it'd create the expectation that :utc_today` can be used interchangably
with Date.utc_today/0 everywhere in the api.
---
All for supporting durations in Date.range/3 of course!
On Wednesday, January 8, 2025 at 10:06:12 PM UTC+1 christ...@gmail.com
wrote:
> > 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.
>
> Regardless of atom/struct/other implementation of a sentinel value, I
> think this is a compelling point: if we're going to expand the range of
> datatypes allowed as arguments to Date+Time functions, we should probably
> offer a stable guard API for callers to leverage.
> Aka a *Date.is_date/1 *guard and *{NativeDateTime,
> DateTime}.is_date_time/1* guards.
>
> I do prefer the idea of a sentinel value to procure a utc_now datetime, to
> minimize the size of the Date+Time APIs. If we pursue this, I think we must
> be very intentional in the documentation about when the sentinel gets
> resolved into a proper Date+Time, though.
> Ex. without clear instruction, I'd expect a struct called *DateTime.Lazy*
> to not get resolved until absolutely required by a Date+Time call that
> actually has to produce a value out of it, ex deferring shifting until
> serialized/stringified or a subcomponent is extracted.
> My understanding that is not what's being proposed, though—rather that any
> Date+Time callsite that recieves the sentinel will immediately procure a
> proper utc_now Date+Time.
> This ambiguity may be more a problem with the proposed term "Lazy" than
> anything else, but I think the docs would need to make resolution time
> crystal clear no matter the terminology chosen.
>
> On Wednesday, January 8, 2025 at 1:01:30 PM UTC-6 José Valim wrote:
>
>> I don't think I would worry about precision shortcuts for those APIs:
>>
>> 1. You can truncate after anyway. If the precision is not relevant to the
>> operation, then after should have the same result. If it is important, then
>> you want to either leave it or be explicit
>> 2. Some operations don't return a Date/Time and therefore may not care
>> about precision either
>>
>>
>> *José Valimhttps://dashbit.co/ <https://dashbit.co/>*
>>
>>
>> On Wed, Jan 8, 2025 at 7:55 PM Wojtek Mach <woj...@wojtekmach.pl> wrote:
>>
>>> Btw, one of somewhat recent nice ergonomic improvement was replacing:
>>>
>>> DateTime.utc_now() |> DateTime.truncate(:second)
>>>
>>> with:
>>>
>>> DateTime.utc_now(:second)
>>>
>>> I think it might be relevant for the proposal. Is either of these
>>> appealing?
>>>
>>> # option 1
>>> DateTime.from_utc_now(:seconds, hour: 1)
>>> # option 2
>>> DateTime.from_utc_now([hour: 1], :seconds)
>>>
>>> On the other hand, do we instead add :utc_now, :utc_now_seconds, and
>>> possibly others? I’m not sure.
>>>
>>> If supporting precision is important, to me
>>> DateTime.from_utc_now(duration, precision \\ :microsecond) feels like the
>>> best option after all.
>>>
>>>
>>>
>>> --
>>> 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/8BC8C9BF-BA83-49A0-BD07-91E789B3BAE8%40wojtekmach.pl
>>> .
>>>
>>
--
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/0ef7c69a-63af-41ae-b382-4eced153dcbdn%40googlegroups.com.
