Re: std.datetime questions
== Quote from Jonathan M Davis (jmdavisp...@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.
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
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
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
Re: std.datetime questions
== Quote from Jonathan M Davis (jmdavisp...@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.
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
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.
