Proposal for custom time string formatting in std.datetime
Kagamin
spam at here.lot
Tue Dec 27 06:41:59 PST 2011
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.
More information about the Digitalmars-d
mailing list