std.datetime questions

[Nicholas]

== Quote from Jonathan M Davis (jmdavisProg at 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.