Perhaps the introduction of a function compare_date/2,3 and/or compare_time/2/3.
To demonstrate the thought:
A = "2013-09-01 10am CST",
B = "2013-09-01 12pm CST",
C = "2013-09-02 12am CST",
D = "2013-09-02 12am EST",
qdate:compare_date(A,B).
%% returns 0
qdate:compare_date(A,C).
%% returns -1
qdate:compare_date(C,D).
%% returns ??.
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.
Perhaps the introduction of a function
compare_date/2,3and/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.