Re: [boost] [gsoc 13] Questions regarding Boost::chrono and as well as Boost::chrono/date

Subject: Re: [boost] [gsoc 13] Questions regarding Boost::chrono and as well as Boost::chrono/date
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-01 06:50:15

Le 01/05/13 11:02, Rob Stewart a écrit :
> On Apr 30, 2013, at 3:14 PM, Anurag Kalia <anurag.kalia_at_[hidden]> wrote:
>
>> Are timezones other than utc and local important? Unix, Boost.date_time and Boost.chrono seem to support
>> these two timezones only. What are the motivations to restrict timezones to these two instances? They seem to be the minimum possible set required to display time. I am still reading up on this stuff, so probably a little more reading will answer this part.
> Time zones are important. UTC and local are critical. Being able to manipulate dates in additional time zones, other than UTC, is very helpful. Consider a multinational corporation consolidating information from multiple sites. Where the program runs dictates the local time zone, which might be used for logging timestamps. The data's source dictates the time zone of time stamps in the data. Neither time zone need be UTC. One could switch the local time zone to that of the data, convert each date/time to UTC, switch local back to its original value, and then use UTC only with the data, but during the switch, the log time stamps would be wrong.
Rob, do you think timezones are must have feature for a Date library?
> One of the flaws in Boost.Datetime is the time zone support only accounts for two changes per year: DST on and off. However, other changes can be legislated any given year. Another deficiency you might consider addressing is multi-year time zone support. That is, based upon the date/time being represented, which time zone rules apply?
>
> Know that you cannot please all interested parties with a single date/time class. Special cases often require special purpose classes and need not, necessarily, be standardized. Look to other programming languages and libraries for inspiration and scope.
>
Note that my intention here is to explore the domain, not making a C++ 
standard proposal.
I suspect that the proposal to the standard would contain only one date 
class. Having a library that shows that we could have several date 
classes that works well together could make the the committee switch 
from a concrete date class specification to a Date concept and one 
possible implementation.

Best,
Vicente