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 _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
