std.datetime questions
Jonathan M Davis
jmdavisProg at gmx.com
Sat Mar 12 00:32:02 PST 2011
On Friday 11 March 2011 19:34:26 Jonathan M Davis wrote:
> On Friday, March 11, 2011 19:18:21 Nicholas wrote:
> > 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.
>
> I assume that you were using WindowsTimeZone then?
>
> > 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.
>
> Yeah. std.date is pretty broken. So, there hasn't really been even a decent
> solution for date/time stuff in Phobos for a while, but std.datetime should
> fix that. And it's definitely designed in such a way that it's at least
> _supposed_ to handle time zones really well and fairly painlessly. Only
> time and usage will tell how good the design really is though. I think
> that it's quite solid overall, but I'm not about to claim that it's
> perfect. And while bugs in it should be rare given how thoroughly tested
> it is, I'm not about to claim that there definitely aren't any. Definitely
> report any that you find.
>
> If I have time, I may mess around with America/New_York a bit this weekend
> and see if anything obvious pops up. Glancing at WindowsTimeZone, I see
> that it's missing some unit tests, so I definitely need to add some,
> regardless of whether there's currently anything wrong with it.
Okay. It looks like WindowsTimeZone gets the UTC offsets reversed. So, in the
case of America/New_York, you'd get UTC+5 instead of UTC-5.
http://d.puremagic.com/issues/show_bug.cgi?id=5731
I'll try and get it fixed this weekend. I should have caught that before, but
apparently I forgot to create all of the appropriate tests for WindowsTimeZone.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list