On Thursday, March 08, 2012 16:18:39 James Miller wrote: > On 8 March 2012 15:56, Jonathan M Davis <jmdavisp...@gmx.com> wrote: > > On Thursday, March 08, 2012 01:22:42 Stewart Gordon wrote: > >> On 07/03/2012 08:10, Jacob Carlborg wrote: > >> <snip> > >> > >> > Yeah, Clock.now() would be good and Data.today() as well. > >> > >> My utility library has, for consistency, DateValue.now, TimeValue.now and > >> DateTime.now. > > > > I specically avoided giving a way to get the time with any type other than > > SysTime (and TickDuration for using a monotonic clock), because I believe > > that it leads to incorrect behavior. Any time that you're dealing with > > the system clock, you should be dealing with SysTime. Date, TimeOfDay, > > and DateTime are for when you need the date and/or time but don't care > > about what absolute time it's associated with in the real world. Treating > > DateTime as corresponding to a specific point in time is just going to > > cause problems, because it has no time zone. It could correspond to over > > 24 different times. By restricting getting the time to SysTime, it > > encourages the writing of correct code. > > > > - Jonathan M Davis > > It tends to be better to go for proper timezoned code from the outset, > a workmate just had to add timezone support to the entire app > recently, took him about 2 weeks.
Definitely. The whole reason that I wrote std.datetime and that SysTime works the way that it does is because I've had to deal with enough time-related bugs at work that I was sick of it, and I wanted to make sure that D had a solution that did it right. And by maintaining its time in UTC internally and just adjusting the time to a particular time zone when required for output (e.g. getting the year of the SysTime or converting it to a string), a whole host of conversion errors are avoided (DST is _the_ largest mistake with regards to time in the history of computing IMHO). Unfortunately, errors are still possible (e.g. sometimes you have to create a SysTime from a DateTime, and that can't be done without risking DST-related errors), but I believe that SysTime manages to reduce them about as much as is possible. So, in general, if you use SysTime, time should just be handled correctly without you having to worry about all of the details - like the time zone. But it also gives you the power to do more if you _do_ care about the details (e.g. selecting a specific time zone). - Jonathan M Davis