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