[phobos] Status of std.gregorian

[Jonathan M Davis]

On Saturday 14 August 2010 23:58:17 Shin Fujishiro wrote:
> > I'm not quite sure what the overall design plan is for std.gregorian, but
> > due to having to deal with various time-related issues at work, I'm 100%
> > convinced that the correct way to write time code is to have
> > _everything_ in UTC until you actually need it in local time, and at
> > that point you do a conversion (likely to a string); the time/date class
> > however would _always_ be in UTC internally. I've seen way too many
> > timezone and DST issues to think that any other way of doing it makes
> > sense. time_t is always in UTC, though unfortunately most of the posix
> > functions (and likely Windows API functions as well) translate to local
> > time when converting time_t to anything else, which makes it quite easy
> > to introduce conversion bugs into code (especially when DST rolls
> > around).
> 
> I agree.  UTC and local time must be different in types, or at least
> timezone and DST information should accompany time data.

If you are ever going to be converting time from one time zone to another, then 
you need to have the internal time in UTC _always_. When you go to present the 
time (be it as a string or getting a particular field like hour or whatever), you 
can do a conversion form the internal UTC to whatever timezone then, but if you 
try and actually have the time in a timezone other than UTC and then convert it 
to another timezone (be it UTC or some other timezone), you're going to be in 
trouble. You can always convert from UTC to another timezone given the 
information for that timezone (including DST info), but you can't always convert 
from a timezone that has DST to one that doesn't. The problem is the 1 hour in 
Spring which doesn't exist and the 1 hour in Fall which happens twice. In 
particular, if you have between 1:00 and 1:59 on the Sunday in Fall when the 
time changes, you cannot possibly know _which_ of the two hours you're in. If 
your times are in UTC, the conversion is easy. But once you're in a timezone 
with DST, you don't have the necessary information, and you're screwed. I've 
dealt with enough time and DST issues at work, that I pretty much wish that the 
whole world lived in UTC - or at minimum that DST didn't exist. It just makes 
dealing with time in programs a royal pain to get right.

In any case, ideally, whatever we do for time/date in Phobos is in UTC 
internally and properly handles conversions to other timezones upon request, but 
it isn't ever actually in another timezone internally.

- Jonathan M Davis