Jonathan M Davis <[email protected]> wrote: > As for its design, it looks like it's holding the number of days as a ulong > with > nothing more precise than that. I would have expected a time_t or equivalent > with the number of seconds or milliseconds since the epoch. So, that makes it > look like it doesn't care about anything more precise than days, which would > be > insanely limiting if it's supposed to be replacing the buggy std.date.
I reckon the Date is pure date and time is supposed to be represented by another type (not yet defined?). I think that a pure date should be represented by 24h time interval though. > 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. Shin _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
