www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.datetime questions

reply Nicholas <maybe later.com> writes:
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.
Mar 11 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Mar 11 2011
parent reply Nicholas <maybe later.com> writes:
== 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.

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.

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;

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.

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.
Mar 11 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Mar 12 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 12 2011
prev sibling parent Nicholas <maybe later.com> writes:
== 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.

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.
Mar 14 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Mar 11 2011