Article Review: Migrating from std.date to std.datetime

[Rainer Schuetze]

Thanks a lot for writing the article. I was just about to get rid of 
std.date and migrate to std.datetime, so it's perfect timing. ;-)

A few nitpicks:

- a short motivation for using hecto-nano-seconds would be nice, it's 
not really the most obvious choice.

- Reading this code:

 > d_time dTime = "myfile.txt".lastModified();
 > SysTime sysTime = "myfile.txt".timeLastModified();

Using UFCS distracted me quite a bit from the actual point, better use 
standard call syntax.

When migrating, I hit a few problems:

- there is an alias for std.string.indexOf in std.datetime, that causes 
ambiguities when imported with other modules. (AFAICT it is used to 
disambiguate std.algorithm.indexOf and std.string.indexOf, which are bad 
by themselves, but it'd be better to use explicite std.string.indexOf in 
the few places in std.datetime).

- the documentation for std.datetime.WindowsTimeZone is missing on the 
website

- the documentation for std.file.getTimesWin/Posix is not found on the 
website (why the different function names?)

- my current uses of datetime are comparing file times and displaying 
the file time. Much better than std.date, the times displayed are now 
the same as shown by Explorer/dir most of the time, but some are off by 
one hour. It seems this happens for times with a different daylight 
saving. Is this a bug? Or do I need to call something else than

writeln(timeLastModified(file).toSimpleString());

The ISO versions or conversion to DateTime produce the same output. My 
local time is UTC+1+DST.

- running the unittests for std.datetime takes more than 10 minutes 
until it assert here:

Failed time zone: America/Los_Angeles
core.exception.AssertError at std\datetime.d(27696): _assertPred!"==" 
failed: [Pazifik Normalzeit] is not == [Pacific Standard Time].

It seems the test strings need to be localized aswell.

Do the tests also run this long under linux? My impression from stopping 
execution inside a debugger is that constructing SysTime is rather slow 
(most time seems to be spent in SystemTimeToTzSpecificLocalTime).

Rainer


Jonathan M Davis wrote:
> It recently came to my attention that an article on converting code from using 
> std.date to using std.datetime would be of value, so I wrote one up. Since 
> it's an article, and it's within the time period set by Walter for the article 
> contest, I guess that it's in the article contest, but I wrote it because it 
> needed writing rather than for the contest. It might as well be part of the 
> contest though.
> 
> In any case, I put it in my d-programming-language.org repository on github: 
> https://github.com/jmdavis/d-programming-language.org/tree/article_datetime
> 
> Or if you just want to download it without building d-programming-language.org 
> yourself, go here: http://is.gd/jFAmDy
> 
> So, feel free to read it and give feeback on it. Hopefully it does its job 
> fairly well. Writing it did give me some insight into a couple of tweaks that 
> need to be made to std.datetime though. In particular, I really should come up 
> with a better way to save time zones for those that care about restoring the 
> _exact_ time zone that they had in the SysTime that they saved in a database 
> or to disk or whatever. ISO is great for storing the exact time - including 
> what the offset from UTC of the original time zone was - but it's not 
> generally enough for restoring the exact time zone that you were dealing with 
> in the first place. Most code won't care, but I really should find a way to do 
> it. I knew about the problem, but it's definitely a pain to solve, so I left 
> it alone. I should work on fixing that.
> 
> In any case, the article is now available for you to read and review.
> 
> - Jonathan M Davis