Re: [boost] [gsoc 2013] draft proposal for chrono::date

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Anders Dalvander (boost_at_[hidden])
Date: 2013-05-05 13:07:18

On 2013-05-05 17:37, Anurag Kalia wrote:
> Anders Dalvander-3 wrote
>> Same here, the date May 5th 2013 represent the time range [2013-05-05
>> 00:00, 2013-05-05 24:00), but that time range is different for different
>> people around the world. It would be, in my humble opinion, better to
>> keep `chrono::date` abstract, without any connection to a timezone.
>>
>> Same with `chrono::time` (or whatever it would be called), it could be
>> the time 12:34:56, but that cannot be represented as an instant in time
>> (i.e. `chrono::time_point`). Neither can the combined `chrono::date` and
>> `chrono::time`, it is still without any connection to a timezone.
>> Perhaps it's better to explain myself with code:
>>
>> chrono::date d =ear(2013) / may / day(5);
>> chrono::time t =ours(12) + minutes(34) + seconds(56);
>> chrono::date_time dt(d, t);
>> // Here `dt` should be the representation of May 5th 2013 at 12:34:56,
>> but that in turn occurred at different instants for different people
>> around the world.
>> // In order to convert it to a `system_time` a timezone would be needed:
>> chono::system_time st =t.in_timezone(chrono::timezones::utc); // or
>> perhaps `dt.in_utc()` for short.
>>
>> I believe this is one of the few ways to resolve the many ambiguities of
>> dates and times once and for all.
>>
>> Below is a rant, but first a disclaimer: I like the Boost.DateTime
>> library very much, it has helped me greatly.
>> The Boost.DateTime library has some flaws, one of them is the ambiguity
>> of the `boost::date_time::ptime` class regarding timezones. It can
>> represent time in different timezones, and you never know which. It can
>> be local or UTC, or whatever. It's easy to use it incorrectly, it even
>> have two factory functions (`second_clock::universal_time` and
>> `second_clock::local_time`) which both create a `ptime`, but in
>> different timezones, and after it has been created you can never know
>> which. It can easily be resolved, as described above, and the compiler
>> will tell you if you try to do something wrong.
>> Not even the old C `time_t` had this issue, you are always explicit when
>> converting it to local time (`localtime`) or UTC time (`gmtime`), but
>> here the `tm` struct was used for both.
>>
>> Let's not make the same mistakes once again with `chrono::date`.
> I support you completely. But I feel like we can't even if we wanted to.
> Timezones are separated at intervals of 30 minutes (is it not always so?).
There are timezones at 15 minutes too. Chatham Island Daylight Time 
(CHADT), Chatham Island Standard Time (CHAST) and Nepal Time (NPT). Not 
perhaps the most common, but they should be supported non the less.
> But our dates have precision in terms of days. That creates a dilemma as to
> how do we store this information.
Still the precision of a day is too imprecise to store any timezones, 
even if we only had 1 hour timezones.
> Say, a user enters a date and we store its timezone separately. Then, we
> always want to be able to convert it to UTC for general comparison. But what
> is that date in UTC timezone?
I think you are mixing two concepts: TimePoints (a.k.a. Instants) and Dates.
> It depends on the time at which the date was
> entered. But since our library is date and not datetime, we refused to
> record timepoints in precision below days.
>
> Comparisons etc work in UTC timezone by convention, but user does I/O in
> his/her local timezone. We have demonstrated that converting from one
> timezone to another is not possible with dates only. Thus, our date must be
> naive and be oblivious to timezones at all.
That is easy, enter date in an abstract `chrono::date`, convert i to an 
`chrono::system_clock::time_point` using an explicit timezone (your 
current one, that is). Then you can compare them using the comparison 
functions of `time_point`.

Best regards,
Anders Dalvander