Proposal for custom time string formatting in std.datetime

[Jonathan M Davis]

On Tuesday, December 27, 2011 15:41:59 Kagamin wrote:
> 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.

SysTime holds the time in UTC. It's only ever an issue if you try and create a 
SysTime from a Date or DateTime which fall on a DST switch. And unfortunately, 
that problem is unavoidable, since you sometimes need to be able to specify a 
date and time in the local time zone and convert it to UTC. But creating a 
SysTime from a Date or DateTime shouldn't be something that programs are doing 
frequently. Usually, you get the time from the system clock, in which case, 
it's in UTC, and there are no conversion issues.

> > 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`).

SysTime already keeps the time in UTC. It only converts anything to a specific 
time zone when you ask for a value which requires it (such as getting its 
month or getting it as a string). Adding something like UTCTime adds nothing 
beyond removing the TimeZone object in an effort to reduce the number of 
symbols in the executable for those who just want to compare times, and that 
makes it so that you have to create other types to convert UTCTime to in order 
to get the time in other time zones (e.g. local time). By having SysTime, you 
don't need extra time types.

> > 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%2
> 9.aspx

Yes. That's why you have to tell Linux to have the system clock in local time 
when you dual boot with Windows. Windows puts the system clock in local time. 
Apparently, they did finally make it possible to have it in UTC with either 
Vista or 7 (I don't remember which) if you set a registry setting accordingly, 
but it's not that way by default.

> > 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.

It's problem even for times with time zone information if the time isn't in 
UTC. Using something like UTCTime or SysTime fixes the problem, because the 
time would always be in UTC. The problem is that the code in that program 
_was_ converting time back and forth between local time and UTC.

> > 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.

A SysTime is in UTC and holds a TimeZone which converts the time to that time 
zone when it needs to (e.g. getting the day of that time or converting it to a 
string). The programmer doesn't need to do any conversions with SysTime. If 
they want to change the time zone of the SysTime, they change the SysTime's 
timezone property and then any function which needs to adjust for the time 
zone will use the new TimeZone object. The time itself is always in UTC, so 
there are no conversion problems when changing time zones.

- Jonathan M Davis