Proposal for custom time string formatting in std.datetime

[Kagamin]

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.