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

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Anurag Kalia (anurag.kalia_at_[hidden])
Date: 2013-05-05 11:37:32

Anders Dalvander-3 wrote
> On 2013-05-05 01:33, Vicente J. Botet Escriba wrote:
>> Le 04/05/13 23:09, Howard Hinnant a écrit :
>>> On May 4, 2013, at 4:15 PM, "Vicente J. Botet Escriba" 
>>> <

> vicente.botet@

> > wrote:
>>>> class date;
>>>>
>>>> date today();
>>> In what timezone?
>> UTC
> I thought that `chrono::date` was an abstract representation of a date, 
> and not at all connected to a timezone. And that in order to convert to 
> and from a `chrono::system_clock` or any other clock an explicit 
> timezone would be needed.
>>
>>> What is the internal representation?
>> I'm not talking here of a concrete date class yet, but much more of an 
>> archetype of Date concept. We could see the if it is better to make 
>> concrete classes that provide less as not efficient.
>>
> Exactly, we should discuss the Date concept, and not focus on the 
> concrete *classes*.
>>>
>>>>   explicit date(system_clock::time_point);
>>>>   operator system_clock::time_point() const;
>>> Do the above two assume the UTC timezone?
>> Copy/paste from your original proposal.
>>
>> explicit date(chrono::system_clock::time_point tp);
>>
>>    /Effects:/ |tp| is converted to UTC, and then trucated to 00:00:00
>>    hours. A |date |is created which reflects this point in time.
>>    /Throws:/ If the conversion from |tp| overflows the range of |date|,
>>    throws an exception of type |bad_date|.
>> explicit operator chrono::system_clock::time_point () const;
>>
>>    /Returns:/ A |chrono::system_clock::time_point| which represents the
>>    date referred to by |*this| at 00:00:00 UTC.
>>    /Throws:/ If the conversion to |tp| overflows the range of
>>    |chrono::system_clock::time_point|, throws an exception of type
>>    |bad_date|.
> 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 = year(2013) / may / day(5);
> chrono::time t = hours(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 = dt.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`.
> 
> Best regards,
> Anders Dalvander
> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

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?).
But our dates have precision in terms of days. That creates a dilemma as to
how do we store this information.

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? 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.

--
View this message in context: http://boost.2283326.n4.nabble.com/gsoc-2013-draft-proposal-for-chrono-date-tp4646142p4646718.html
Sent from the Boost - Dev mailing list archive at Nabble.com.