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

     $ TZ=UTC date ; TZ=EST5EDT date       # try GNU date first
     Thu Apr 15 16:31:40 UTC 2010
     Thu Apr 15 12:31:40 EDT 2010

     $ TZ=EST5EDT ./demo
     Thu Apr 15 17:32:02 GMT+0100 2010     # UTC wrong!
     Thu Apr 15 18:32:02 GMT+0100 2010     # Local wrong!

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:
Content-Type: text/plain

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?
 

Apr 16 2010
next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Graham Fawcett wrote:
 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 t=

 D community.
=20

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?

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. :)

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. :)
 

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. :)
 

freepository.com login: demo-lite password: demo repository: demo file: /test/date2.d
Apr 17 2010
prev sibling next 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 next sibling parent 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?
 


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
prev sibling parent 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?

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
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: #!/usr/bin/dmd -run 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 what #2965 is reporting, so I'll file a new issue. 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: #!/usr/bin/dmd -run 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.
 That's not quite what #2965 is reporting, so I'll file a new issue.

...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: #!/usr/bin/dmd -run 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.
 That's not quite what #2965 is reporting, so I'll file a new issue.

...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: #!/usr/bin/dmd -run 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.
 That's not quite what #2965 is reporting, so I'll file a new issue.

...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