You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That last case illustrates the major issue with date comparison.
If C is converted to EST, then it's 2013-09-02 1am, where it would be the same day, whereas if D is converted to CST, then it's 2013-09-01 11pm, in which case it would be different days.
Perhaps the solution is to accept a "Reference Timezone" which both dates would be converted to, or if none is provided to use the timezone stored with set_timezone (which would fall back to GMT).
I'm not entirely sure this is a feasible proposition, and might add too much "magic".
I'd say we should just extract the date portion without even considering the timezone, but what happens when comparing against a unix timestamp or now tuple? Then we would still need to do something with implicit timezones anyway.
The text was updated successfully, but these errors were encountered:
Perhaps the introduction of a function
compare_date/2,3
and/orcompare_time/2/3
.To demonstrate the thought:
That last case illustrates the major issue with date comparison.
If C is converted to EST, then it's 2013-09-02 1am, where it would be the same day, whereas if D is converted to CST, then it's 2013-09-01 11pm, in which case it would be different days.
Perhaps the solution is to accept a "Reference Timezone" which both dates would be converted to, or if none is provided to use the timezone stored with
set_timezone
(which would fall back to GMT).I'm not entirely sure this is a feasible proposition, and might add too much "magic".
I'd say we should just extract the date portion without even considering the timezone, but what happens when comparing against a unix timestamp or now tuple? Then we would still need to do something with implicit timezones anyway.
The text was updated successfully, but these errors were encountered: