> 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/9cda34d2-0446-4c90-a953-482b0870432cn%40googlegroups.com.
