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
On 2013-05-05 17:37, Anurag Kalia wrote: 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