On 2011-05-15 03:34, Rainer Schuetze wrote: > 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.
It's the highest precision that you can have and still have a decent range of values in a 64-bit integer. Going by 10 ns units would result in the range being too small, but 100 ns gives you from around 29,000 B.C. to 29,000 A.D. It's also what C# uses. > - 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). That's a bug. I shouldn't have done that. I didn't think about the alias being public when I did it. It has now been fixed on github. > - the documentation for std.datetime.WindowsTimeZone is missing on the > website I don't know why it would be. It's probably a bug relating to the new StdDdoc versioning that we switched to (instead of using D_Ddoc which screwed up people who build the documentation at the same time as their code - a bad practice IMHO, but we decided to not set it up so that it didn't work when using Phobos). As WindowsTimeZone is only on Windows, it definitely had to be versioned with StdDdoc. > - the documentation for std.file.getTimesWin/Posix is not found on the > website (why the different function names?) Probably a StdDdoc problem as well. As for the different names, the that's because of the fact that they give you different values. Windows has file creation times. Posix does not. Instead, it gives you the last time that the file status was changed (which historically, std.file has mistakenly been returning for the creation time of files on Posix). > - 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. I'd need more data to have any idea what's going on, but it sounds like a bug. > - 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. I didn't even know that time zone strings were ever localized, and there's no way that the unit tests are going to be able to deal with that other than not testing stuff that would ideally be being tested. I'll have to figure out what to about that. > 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). The unit tests have never taken anywhere near that long for me. I'm in the midst of rewriting them though (some of that rewrite was in the last release), so their performance characteristics could change. It tests a lot though, so I'd expect it to take longer than the other Phobos modules. - Jonathan M Davis
