== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article > On Friday, March 11, 2011 12:29:49 Nicholas wrote: > > I just started using the new std.datetime. Two things I find strange that > > maybe someone can explain are: > > > > > > 1) EST timezone displays GMT+0500 instead of -0500 when using any of the > > toString functions. Didn't check other negative timezones. > If it does, that's a bug. Please report it with appropriate details as to what > OS you're using (that matters a lot for std.datetime) and which time zone > class > you were using and whatnot (probably LocalTime unless you were specifically > trying to use another time zone). > > 2) The UTC time for std.file's DirEntry uses milliseconds, so when > > converting SysTime to UTC, I had to use toUnixTime and then I had to > > multiple the result by 1000. > std.file.DirEntry should have older functions which use d_time and newer ones > which use SysTime. No conversion should be necessary. There _are_ functions in > std.datetime for converting between d_time and SysTime if you need to (they'll > go away when std.date does) if you need to convert between those two though. > It > sounds like you're using the d_time versions of DirEntry's functions. Just use > the SysTime versions and you won't need to do any converting (the older > functions are going to go when std.date does as well). > > Also, I found it strange that this wouldn't work: > > > > auto stime = SysTime( ... ); > > long timetest = stime.toUnixTime() * 1000; //doesn't work > > > > I had to do: > > > > timetest = stime.toUnixTime(); > > timetest *= 1000; > My guess would be is what's happening is that time_t can't handle being > multiplied by 1000. long can. In the first case, you're multiplying the > time_t, > not a long. In the second, you're multiplying a long. > > I believe there's also a problem with the time in SysTime when you specify > > a timezone and set the time to 0 in the constructor, e.g. SysTime( > > DateTime( 2011, 3, 11 ), TimeZone( "America/New_York" ) ), in that it > > forces the time to GMT instead of the specified local time. I'll have to > > double check but I know it worked when I used a non-zero time. > You're going to need to be more specific. I don't understand what you're > saying > well enough to try and reproduce it, let alone fix it if there's a problem. > Regardless, if you find any bugs in std.datetime, _please_ report them. As > far as > I know, it's bug free. There are no outstanding bugs on it. It _has_ been > thoroughly tested (and I've actually been working on improving the unit > tests), > but it's mostly been used in Linux in the America/Los_Angeles time zone, and I > haven't tested every time zone under the sun. So, I may have missed something. > - Jonathan M Davis
Thanks for the information. I'll play with it when I'm at work again and then report my findings. In the interim, my timezone is EST. I used TimeZone America/New_York on 32-bit WinXP SP 3. Overall, the library seems like it offers a lot. I found a glaring bug in std.date as well with EST, which was more harmful than the ones I mentioned now.