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.
Great, I didn't know that!
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
No, I am not. When we store a time, we have precision of seconds. When computers got too fast, we made it more and more precise so that we have a precision of nanoseconds now. A day then should be treated as a highly imprecise instant. In datetime library, every timepoint is converted into UTC timezone for direct comparison. 3.00 am in India is still earlier than 1.00 am in Greenwich, in the same day. So we subtract 5 hours 30 minutes from Indian time to get time in UTC: then we get that 3.00 am IST is actually 9.30 pm of previous day. Causality is thus not violated. But the implicit and important point is that 3.00 am IST is actually 3.00 am +/- 1 second, IST. And 1.00 am GMT is 1.00 am +/- 1 second, GMT. So, in any case, any instant in the given range of IST is less than any instant in the GMT. Thus, we can say with surity that the event happened at IST timepoint happened before than the event at GMT timepoint. But if we are talking about days, we record only till the day information. So, if I note date right now as 6 May 2013 IST, we can't verifiably convert it to UTC. If the time at which I recorded date (which I failed to note down) was 1.00 am, the date in UTC would be 5 May, 2013. If I record the same date at 6.00 am, date in UTC would be 6 May, 2013. Thus, there is an ambiguity due to the lack of precision of our dates. Now we can assume that the time at which date was recorded is noon, say. I make a timeline that illustrates my point: 2013-05-06T01:00:00+5:30 I sent an email from India. 2013-05-05T21:00:00Z My friend received his email. Converting to UTC, 2013-05-05T19:30:00Z I sent an email from India. 2013-05-05T21:00:00Z My friend received his email. Okay! Causality is not violated. Now, if we record only the date, 2013-05-06 I sent an email from India. 2013-05-05 My friend received his email. Wrong! Causality is violated! Now, if we assume that time is noted at noon and we have recorded timezones too, 2013-05-06T12:00:00+5:30 I sent an email from India. 2013-05-05T12:00:00Z My friend received his email. Converting the values to UTC, 2013-05-06T06:30:00Z I sent an email from India. 2013-05-05T12:00:00Z My friend received his email. Wrong! Causality is violated! Now people may think that maybe noon is the problem. We could choose midnight. But we can always construct examples against it too. The problem is that timezones inherently require a precision in at least 15 minutes, or to make it simpler, 1 minute. This is a domain where dates by themselves are completely unsuitable. If there is deep flaw in my reasoning, I don't know. But the talk of using or not using time zones because they are unsuitable for maintenance seems to miss a big point. I am quite sure that my analysis is correct. If there is one, I am really interested in that. And if there is not, then I would just like to channelize the energy of the whole ML away from time zones. Regards, Anurag. -- View this message in context: http://boost.2283326.n4.nabble.com/gsoc-2013-draft-proposal-for-chrono-date-... Sent from the Boost - Dev mailing list archive at Nabble.com.