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