View mode: basic / threaded / horizontal-split · Log in · Help
March 11, 2011
std.datetime questions
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.


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.


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;


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.
March 11, 2011
Re: std.datetime questions
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
March 12, 2011
Re: std.datetime questions
== Quote from Jonathan M Davis (jmdavisProg@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.
March 12, 2011
Re: std.datetime questions
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.

- Jonathan M Davis
March 12, 2011
Re: std.datetime questions
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
March 12, 2011
Re: std.datetime questions
On 3/12/11 2:32 AM, Jonathan M Davis wrote:
> 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.

Oh noes! :o)

Andrei
March 14, 2011
Re: std.datetime questions
== Quote from Jonathan M Davis (jmdavisProg@gmx.com)'s article
> 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


Not too bad.  At least it's only the display.  It can be corrected with a
std.string.replace until the new version is released.


I did some testing earlier today and didn't run into any other problems.  Thanks
for the reply on working with std.file and std.datetime.
Top | Discussion index | About this forum | D home