www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Problems with std.time and local conversion?

reply fawcett uwindsor.ca writes:
Hi folks,

The std.date library for D2 seems to be buggy with respect to local
timezone conversions:

     // demo.d
     import std.stdio;
     import std.date;

     void main() {
       // UTC first, then local
       writefln(toString(getUTCtime()));
       writefln(toString(UTCtoLocalTime(getUTCtime())));
     }

Compiling and running:

     $ uname -srm
     Linux 2.6.31-20-generic x86_64
     $ dmd | head -1
     Digital Mars D Compiler v2.043

     $ dmd demo.d


     Thu Apr 15 16:31:40 UTC 2010
     Thu Apr 15 12:31:40 EDT 2010

     $ TZ=EST5EDT ./demo



The library it gets it right on TZ=UTC, so the TZ environment variable
is clearly being considered:

     $ TZ=UTC ./demo
     Thu Apr 15 16:32:20 GMT+0000 2010
     Thu Apr 15 16:32:20 GMT+0000 2010

But of course TZ=UTC sidesteps local conversion altogether. I also
tried with TZ=EST but that gives identical results to TZ=UTC.

Can anyone help explain what's happening here? (If it matters, I
installed the i386 .deb package on my x86_64 machine; otherwise I
think this is a typical installation.)

Thanks,
Graham
Apr 15 2010
next sibling parent reply Kagamin <spam here.lot> writes:
fawcett uwindsor.ca Wrote:


 The std.date library for D2 seems to be buggy with respect to local
 timezone conversions


That was mild. I've started std.date redesing some time ago, here you can see
the result, it's still incomplete though.
Apr 15 2010
next sibling parent reply fawcett uwindsor.ca writes:
On 10-04-15 03:43 PM, Kagamin wrote:

 fawcett uwindsor.ca Wrote:


 The std.date library for D2 seems to be buggy with respect to local
 timezone conversions


 That was mild. I've started std.date redesing some time ago, here you can see
the result, it's still incomplete though.


Thanks for sending your in-progress design. Do you have a public 
repository anywhere?

Best,
Graham
Apr 16 2010
parent reply Kagamin <spam here.lot> writes:
fawcett uwindsor.ca Wrote:


 Thanks for sending your in-progress design. Do you have a public 
 repository anywhere?
 


Erm, no. Never heard about public repositories.
Apr 16 2010
parent reply Graham Fawcett <fawcett uwindsor.ca> writes:
On Fri, 16 Apr 2010 16:35:41 -0400, Kagamin wrote:


 fawcett uwindsor.ca Wrote:
 

 Thanks for sending your in-progress design. Do you have a public
 repository anywhere?
 


 Erm, no. Never heard about public repositories.



Sorry, I should have been more clear. I meant, is your code under version 
control, and is the repository publically accessible: for example, in a 
sourceforge, github, or bitbucket site?

It's in part a leading question. I'm new to this list, and am trying to 
get a sense of how third-party-library development tends to happen in the 
D community.

Best,
Graham
Apr 16 2010
next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Graham Fawcett wrote:

 It's in part a leading question. I'm new to this list, and am trying to=


=20

 get a sense of how third-party-library development tends to happen in t=


he=20

 D community.
=20


	Well, a lot of it is on http://dsource.org

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Apr 17 2010
prev sibling parent reply Kagamin <spam here.lot> writes:
Graham Fawcett Wrote:


 Erm, no. Never heard about public repositories.


 
 Sorry, I should have been more clear. I meant, is your code under version 
 control, and is the repository publically accessible: for example, in a 
 sourceforge, github, or bitbucket site?
 


No, my code is on my hdd, never heard about publically accessible repositories,
sf is private, git was meant to be more public, though it's too linux-centric,
I'll look into bitbucket.
Apr 17 2010
parent reply Graham Fawcett <fawcett uwindsor.ca> writes:
On Sat, 17 Apr 2010 10:33:40 -0400, Kagamin wrote:


 Graham Fawcett Wrote:
 

 Erm, no. Never heard about public repositories.


 
 Sorry, I should have been more clear. I meant, is your code under
 version control, and is the repository publically accessible: for
 example, in a sourceforge, github, or bitbucket site?
 


 No, my code is on my hdd, never heard about publically accessible
 repositories, sf is private, git was meant to be more public, though
 it's too linux-centric, I'll look into bitbucket.


Okay. Well, I hope bitbucket will be public enough for you, but somehow I 
doubt it. :)

Best,
Graham
Apr 17 2010
next sibling parent Kagamin <spam here.lot> writes:
Graham Fawcett Wrote:


 No, my code is on my hdd, never heard about publically accessible
 repositories, sf is private, git was meant to be more public, though
 it's too linux-centric, I'll look into bitbucket.


 
 Okay. Well, I hope bitbucket will be public enough for you, but somehow I 
 doubt it. :)
 


Well, if you really need it, you can put anywhere you want, you have the source.
Apr 17 2010
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Graham Fawcett Wrote:


 Okay. Well, I hope bitbucket will be public enough for you, but somehow I 
 doubt it. :)
 


Do you know something like pastebin?
Apr 17 2010
prev sibling parent Kagamin <spam here.lot> writes:
Graham Fawcett Wrote:


 Okay. Well, I hope bitbucket will be public enough for you, but somehow I 
 doubt it. :)
 


You can find it here:
freepository.com
login: demo-lite
password: demo
repository: demo
file: /test/date2.d
Apr 17 2010
prev sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
On Thu, 15 Apr 2010 15:43:59 -0400, Kagamin wrote:


 fawcett uwindsor.ca Wrote:
 

 The std.date library for D2 seems to be buggy with respect to local
 timezone conversions


 
 That was mild. I've started std.date redesing some time ago, here you
 can see the result, it's still incomplete though.


I bleated about this for ages. In the end wrote my own, or rather wrote a 
wrapper over the stuff in the C standard library. There's a lot of work 
in the local time and Julian calender stuff - why re-invent the wheel?

Steve
Apr 16 2010
parent Kagamin <spam here.lot> writes:
Steve Teale Wrote:


 I bleated about this for ages. In the end wrote my own, or rather wrote a 
 wrapper over the stuff in the C standard library. There's a lot of work 
 in the local time and Julian calender stuff - why re-invent the wheel?


I work only with gregorian calendar, and I'm not sure that the wheel is
invented. Only local time and string conversions in todo.
Apr 16 2010
prev sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
This bug was reported:

http://d.puremagic.com/issues/show_bug.cgi?id=2965
Apr 15 2010
parent reply fawcett uwindsor.ca writes:
On 10-04-15 05:10 PM, Jesse Phillips wrote:

 This bug was reported:

 http://d.puremagic.com/issues/show_bug.cgi?id=2965


Ah, thank you. I see that importing std.datebase does indeed give
better results, though still not perfectly so:



     import std.datebase;
     import std.stdio;
     import std.date;

     void main() {
       // UTC first, then local
       writefln("UTC:   %s", toString(getUTCtime()));
       writefln("Local: %s", toString(UTCtoLocalTime(getUTCtime())));
     }

$ TZ=EST5EDT ./timedemo.d
UTC:   Fri Apr 16 08:56:04 GMT-0400 2010
Local: Fri Apr 16 04:56:04 GMT-0400 2010

The time is right, but the the tzoffset is wrong. That's not quite


Thanks!
Graham
Apr 16 2010
parent reply fawcett uwindsor.ca writes:
On 10-04-16 09:03 AM, fawcett uwindsor.ca wrote:

 On 10-04-15 05:10 PM, Jesse Phillips wrote:

 This bug was reported:

 http://d.puremagic.com/issues/show_bug.cgi?id=2965


 Ah, thank you. I see that importing std.datebase does indeed give
 better results, though still not perfectly so:



 import std.datebase;
 import std.stdio;
 import std.date;

 void main() {
 // UTC first, then local
 writefln("UTC: %s", toString(getUTCtime()));
 writefln("Local: %s", toString(UTCtoLocalTime(getUTCtime())));
 }

 $ TZ=EST5EDT ./timedemo.d
 UTC: Fri Apr 16 08:56:04 GMT-0400 2010
 Local: Fri Apr 16 04:56:04 GMT-0400 2010

 The time is right, but the the tzoffset is wrong.


Correction to my observation: the time component is messed up too, it
was 08:56 local time when I ran this, not 04:56.





...which I'll still do.

Best,
Graham
Apr 16 2010
parent reply Bernard Helyer <b.helyer gmail.com> writes:
On 17/04/10 01:12, fawcett uwindsor.ca wrote:

 On 10-04-16 09:03 AM, fawcett uwindsor.ca wrote:

 On 10-04-15 05:10 PM, Jesse Phillips wrote:

 This bug was reported:

 http://d.puremagic.com/issues/show_bug.cgi?id=2965


 Ah, thank you. I see that importing std.datebase does indeed give
 better results, though still not perfectly so:



 import std.datebase;
 import std.stdio;
 import std.date;

 void main() {
 // UTC first, then local
 writefln("UTC: %s", toString(getUTCtime()));
 writefln("Local: %s", toString(UTCtoLocalTime(getUTCtime())));
 }

 $ TZ=EST5EDT ./timedemo.d
 UTC: Fri Apr 16 08:56:04 GMT-0400 2010
 Local: Fri Apr 16 04:56:04 GMT-0400 2010

 The time is right, but the the tzoffset is wrong.


 Correction to my observation: the time component is messed up too, it
 was 08:56 local time when I ran this, not 04:56.





 ...which I'll still do.

 Best,
 Graham



Yeah, I found std.date to be completely broken, too. Sometimes UTC is 
localtime, and sometimes localtime is UTC, DST is wrong, the list goes 
on and on and on. I think that until the bugs are fixed, std.date should 
be removed from Phobos as it is almost impossible to use it and not hit 
a bug. I feel the same way about std.xml.
Apr 16 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 04/16/2010 08:54 AM, Bernard Helyer wrote:

 On 17/04/10 01:12, fawcett uwindsor.ca wrote:

 On 10-04-16 09:03 AM, fawcett uwindsor.ca wrote:

 On 10-04-15 05:10 PM, Jesse Phillips wrote:

 This bug was reported:

 http://d.puremagic.com/issues/show_bug.cgi?id=2965


 Ah, thank you. I see that importing std.datebase does indeed give
 better results, though still not perfectly so:



 import std.datebase;
 import std.stdio;
 import std.date;

 void main() {
 // UTC first, then local
 writefln("UTC: %s", toString(getUTCtime()));
 writefln("Local: %s", toString(UTCtoLocalTime(getUTCtime())));
 }

 $ TZ=EST5EDT ./timedemo.d
 UTC: Fri Apr 16 08:56:04 GMT-0400 2010
 Local: Fri Apr 16 04:56:04 GMT-0400 2010

 The time is right, but the the tzoffset is wrong.


 Correction to my observation: the time component is messed up too, it
 was 08:56 local time when I ran this, not 04:56.





 ...which I'll still do.

 Best,
 Graham



 Yeah, I found std.date to be completely broken, too. Sometimes UTC is
 localtime, and sometimes localtime is UTC, DST is wrong, the list goes
 on and on and on. I think that until the bugs are fixed, std.date should
 be removed from Phobos as it is almost impossible to use it and not hit
 a bug. I feel the same way about std.xml.


Additional details about the brokenness of std.date in the form of 
bugzilla entries would be very welcome!

Andrei
Apr 16 2010