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

On Wednesday, 28 December 2011 at 00:15:00 UTC, Jonathan M Davis wrote:
> By having SysTime, you don't need extra time types.

Hmm... if you don't have extra time types, how do you format a SysTime? To convert a SysTime to a string you usually need year, month and day. Calculating a year takes some time: leap years, possibly time zone adjustment; when you need month, you have to recalculate year, since SysTime doesn't hold it. That's how it works?

On Wednesday, December 28, 2011 11:39:16 Kagamin wrote:
> On Wednesday, 28 December 2011 at 00:15:00 UTC, Jonathan M Davis
> 
> wrote:
> > By having SysTime, you don't need extra time types.
> 
> Hmm... if you don't have extra time types, how do you format a SysTime? To convert a SysTime to a string you usually need year, month and day. Calculating a year takes some time: leap years, possibly time zone adjustment; when you need month, you have to recalculate year, since SysTime doesn't hold it. That's how it works?

SysTime's time is held internally as a long holding the number of hecto- nanoseconds (100 ns) from midnight, January 1st, 1 A.D.  It also holds a TimeZone which is used to convert that time to the correct time zone when any function requires that the time be in a specific time zone (e.g. getting the year of the SysTime or converting it to a string). SysTime does all of the appropriate calculations for that. And if you want to change the time zone of a SysTime, you set its timezone property to the TimeZone that you want. Its internal time is always in UTC.

And yes, if you access any function or property of SysTime which needs the time in any format other than hnsecs from midnight January 1st, 1 A.D., it has to do the appropriate calculations, even if it's done them before. That's why it can be more efficient to convert a SysTime to a DateTime if you need access its properties a bunch of times in a row. But as long as you don't create a SysTime from that DateTime, you shouldn't have conversion problems.

You _do_ have potential conversion issues if you set a property on a SysTime (e.g. the year), since it has to convert it to its time zone and back again to do that, but there's no way around that unfortunately. However, adding and subtracting durations from a SysTime have no problems at all, because you don't have to do any conversions. It's just setting a property that must be in the SysTime's time zone (e.g. the year or month) which could have conversion issues.

- Jonathan M Davis

On Wednesday, December 28, 2011 03:03:30 Jonathan M Davis wrote:
> On Wednesday, December 28, 2011 11:39:16 Kagamin wrote:
> > On Wednesday, 28 December 2011 at 00:15:00 UTC, Jonathan M Davis
> > 
> > wrote:
> > > By having SysTime, you don't need extra time types.
> > 
> > Hmm... if you don't have extra time types, how do you format a SysTime? To convert a SysTime to a string you usually need year, month and day. Calculating a year takes some time: leap years, possibly time zone adjustment; when you need month, you have to recalculate year, since SysTime doesn't hold it. That's how it works?
> 
> SysTime's time is held internally as a long holding the number of hecto- nanoseconds (100 ns) from midnight, January 1st, 1 A.D.  It also holds a TimeZone which is used to convert that time to the correct time zone when any function requires that the time be in a specific time zone (e.g. getting the year of the SysTime or converting it to a string). SysTime does all of the appropriate calculations for that. And if you want to change the time zone of a SysTime, you set its timezone property to the TimeZone that you want. Its internal time is always in UTC.

And actually, this would be the same with UTCTime if we were to create it. It would hold its time internally as a long in hnsecs, and if it had any functions which required the time in any other format, it would have to convert. It would effectively be a SysTime with UTC as its time zone, except that the time zone would be hard-coded instead of using a TimeZone and its time zone being settable.

- Jonathan M Davis

Could I jump back to the original proposal...

Two years after this thread started, I find there is no way to print a datetime string in the format I desire..  D doesn't have the functionality of strftime(), but does have a hundred or so functions that do related, but not quite right, things..

Could this change?

On Thursday, March 07, 2013 00:39:06 Iain S wrote:
> Could I jump back to the original proposal...
> 
> Two years after this thread started, I find there is no way to print a datetime string in the format I desire..  D doesn't have the functionality of strftime(), but does have a hundred or so functions that do related, but not quite right, things..
> 
> Could this change?

Of course it could change, and it will, but a design must be agreed upon, and I've been very busy of late, so I haven't been doing a lot with D, and this has definitely fallen by the wayside. I need to get back to it, and I will. I just haven't yet. And coming up with a design that's both easy to use and very flexible is difficult. But some variation of what's been discussed will likely end up getting into Phobos at some point.

- Jonathan M Davis