Boost logo

Boost :

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

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

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.


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at