On Tuesday, 27 December 2011 at 10:51:25 UTC, Jonathan M Davis
wrote:
On the other hand, let's say that on 2 am on October 30th, the
time falls back to 1:00 am taking that time zone out of DST.
That means that the times of 1 am up to (but not including) 2
am happen twice. So, if you have the time 1:30 am in local
time, what time is it in UTC? You can't know. It could be
either. The time code is going to have to pick one or the
other, but since 1:30 am is non-
unique, it's not necessarily going to have the behavior which
is correct for your program.
how std.datetime works in this case? You need UTC value for
SysTime.
So, if you want to deal with time accurately and reliably, you
need to always keep the time in UTC until you _need_ to convert
it to local time (typically for display purposes but also for
things like if you need to know something along the lines of
what year that time is in in the local time zone).
True. That's why UTCtime proposed earlier makes perfect sense
(I'd call it just `Time`).
Code which converts time back and forth between UTC and local
time is asking for trouble. Even if it gets all of the
conversions correct (or at least as correct as possible), it's
going to have issues whenever a DST change occurs. That's one
of the reasons why non-Windows OSes typically want to put the
system clock in UTC and what it's so horrible that Windows
normally puts the system clock in local time
Are you sure?
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724390%28v=vs.85%29.aspx
Where I work, we ended up with a bug where when you rewinded
video and you were east of UTC, it would rewind one hour too
far for each hour east of UTC that you were (so 2 hours east of
UTC would rewind 2 hours and 1 second instead of 1 second). It
turns out that the code had been converting a time value to UTC
from local time when it was already in UTC (or it might have
been the other way around - I don't recall exactly which at the
moment).
As far as I understand, this is a problem only for time values
that bear no time zone information and not a problem for, say,
UTCtime: when you convert UTCtime to UTC, you get the same value.
Times should be kept in UTC as much as possible and converted
as little as possible. Anything else is asking for trouble.
That's also one reason why it's good to have times be objects
rather than naked numbers. It reduces the risk of people
converting them incorrectly. SysTime mostly avoids the whole
issue by encapsulating the time (in UTC) with a time zone,
making it so that it generally "just works."
One can convert std.datetime.SysTime value to local time just by
adding a corresponding offset. That should be easy.
