www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.date time problem

reply Regan Heath <regan netmail.co.nz> writes:
I think this is a bug, but I can't be sure.

[time.d]
import std.stdio, std.date;

void main()
{
	d_time now = UTCtoLocalTime(getUTCtime());
	writefln("%s", toTimeString(now));
}

dmd -run time.d
10:54:42 GMT+0100

time /t
09:55

I am in London so at GMT, but it's summer so we're at +0100 currently 
(aka BST).  It seems std.date adds an extra hour?

Regan
Aug 21 2007
next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Regan Heath wrote:

 I think this is a bug, but I can't be sure.
 
 [time.d]
 import std.stdio, std.date;
 
 void main()
 {
     d_time now = UTCtoLocalTime(getUTCtime());
     writefln("%s", toTimeString(now));
 }
 
 dmd -run time.d
 10:54:42 GMT+0100
 
 time /t
 09:55
 
 I am in London so at GMT, but it's summer so we're at +0100 currently
 (aka BST).  It seems std.date adds an extra hour?
 


Yep, it's buggy. std.date does essentially the following in getLocalTZA() on
Windows (shortened to pseudocode):

TIME_ZONE_INFORMATION tzi;
GetTimeZoneInformation(&tzi);

if (unknown time zone || in standard time || in daylight savings time)
	return -(tzi.Bias + tzi.StandardBias) * 60 * TicksPerSecond;
else
	return 0; // error

Microsoft documents at http://msdn2.microsoft.com/en-us/library/ms725481.aspx
that:

- "Bias" is "[t]he current bias for local time translation on this computer, in
minutes" and "UTC = local time + bias".

- "StandardBias" is "[t]he bias value to be used during local time translations
that occur during standard time."

- "DaylightBias" (not used in std.date) is "[t]he bias value to be used during
local time translations that occur during daylight saving time."

That is, UTC = local time + Bias + StandardBias, or UTC = local time + Bias +
DaylightBias, depending on whether DST is active or not.

However, Phobos uses StandardBias in all cases. It should use DaylightBias if
GetTimeZoneInformation returns TIME_ZONE_ID_DAYLIGHT.

In London, I presume that Bias is 0, StandardBias is 0, and DaylightBias is -60,
which is why std.date is wrong.

-- 
Remove ".doesnotlike.spam" from the mail address.
Aug 21 2007
parent Regan Heath <regan netmail.co.nz> writes:
Deewiant wrote:

 Regan Heath wrote:

 I think this is a bug, but I can't be sure.

 [time.d]
 import std.stdio, std.date;

 void main()
 {
     d_time now = UTCtoLocalTime(getUTCtime());
     writefln("%s", toTimeString(now));
 }

 dmd -run time.d
 10:54:42 GMT+0100

 time /t
 09:55

 I am in London so at GMT, but it's summer so we're at +0100 currently
 (aka BST).  It seems std.date adds an extra hour?


 
 Yep, it's buggy. std.date does essentially the following in getLocalTZA() on
 Windows (shortened to pseudocode):
 
 TIME_ZONE_INFORMATION tzi;
 GetTimeZoneInformation(&tzi);
 
 if (unknown time zone || in standard time || in daylight savings time)
 	return -(tzi.Bias + tzi.StandardBias) * 60 * TicksPerSecond;
 else
 	return 0; // error
 
 Microsoft documents at http://msdn2.microsoft.com/en-us/library/ms725481.aspx
that:
 
 - "Bias" is "[t]he current bias for local time translation on this computer, in
 minutes" and "UTC = local time + bias".
 
 - "StandardBias" is "[t]he bias value to be used during local time translations
 that occur during standard time."
 
 - "DaylightBias" (not used in std.date) is "[t]he bias value to be used during
 local time translations that occur during daylight saving time."
 
 That is, UTC = local time + Bias + StandardBias, or UTC = local time + Bias +
 DaylightBias, depending on whether DST is active or not.
 
 However, Phobos uses StandardBias in all cases. It should use DaylightBias if
 GetTimeZoneInformation returns TIME_ZONE_ID_DAYLIGHT.
 
 In London, I presume that Bias is 0, StandardBias is 0, and DaylightBias is
-60,
 which is why std.date is wrong.


Thanks, I'm going to post this to bugzilla.

Regan
Aug 21 2007
prev sibling next sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Regan Heath wrote:

 I think this is a bug, but I can't be sure.


I filed Issue 1436 in the 'Zilla.

(I thought I already had, as I ran into this myself a few weeks ago. Good thing
that you reminded me. <g>)

-- 
Remove ".doesnotlike.spam" from the mail address.
Aug 21 2007
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Regan Heath Wrote:


 I think this is a bug, but I can't be sure.


Yes, in your code.

<snip>

 	d_time now = UTCtoLocalTime(getUTCtime());
 	writefln("%s", toTimeString(now));


<snip>

http://www.digitalmars.com/d/archives/digitalmars/D/learn/3205.html

"It isn't documented but the input to toTimeString() is assumed to be UTC, and
it outputs a Local time string."

Stewart.
Aug 21 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
Stewart Gordon wrote:

 Regan Heath Wrote:
 

 I think this is a bug, but I can't be sure.


 
 Yes, in your code.
 
 <snip>

 d_time now = UTCtoLocalTime(getUTCtime()); writefln("%s",
 toTimeString(now));


 <snip>
 
 http://www.digitalmars.com/d/archives/digitalmars/D/learn/3205.html
 
 "It isn't documented but the input to toTimeString() is assumed to be
 UTC, and it outputs a Local time string."


Ahhh.  Ick.  That's a bit counter-intuitive no?

I'd prefer timezone conversions to be restricted to the explicit calls 
UTCtoLocalTime and LocalTimetoUTC.

I'd also like to be able to convert from d_time to Date and back again 
without having to go:

d_time -> char[] -> parse -> Date

In other words, unless I'm mistaken, currently the only way to get a 
Date is from a string/char[].

What's wrong with the model used by ANSI C?  time, localtime, gmtime, 
asctime, mktime, etc.

Regan

p.s. One really annoying bug I discovered some years ago was that the M$ 
time library and the borland one were incompatible, one applied timezone 
changes in time (and presumably reversed it in gmtime), the other in 
localtime.  It manifested when linking a program compiled in one linking 
to a dll compiled in the other.  Ick.
Aug 22 2007
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Regan Heath" <regan netmail.co.nz> wrote in message 
news:fagv8h$24kn$1 digitalmars.com...

 Stewart Gordon wrote:


<snip>

 "It isn't documented but the input to toTimeString() is assumed to be
 UTC, and it outputs a Local time string."


 Ahhh.  Ick.  That's a bit counter-intuitive no?

 I'd prefer timezone conversions to be restricted to the explicit calls 
 UTCtoLocalTime and LocalTimetoUTC.


<snip>

AISI the problem is that d_times can be in an arbitrary mix of time zones, 
yet don't contain time zone information.

My utility library

http://pr.stewartsplace.org.uk/d/sutil/

does it better - a DateTime or TimeValue is always stored in UTC.

Stewart.
Aug 23 2007
parent Regan Heath <regan netmail.co.nz> writes:
Stewart Gordon wrote:

 "Regan Heath" <regan netmail.co.nz> wrote in message 
 news:fagv8h$24kn$1 digitalmars.com...

 Stewart Gordon wrote:


 <snip>

 "It isn't documented but the input to toTimeString() is assumed to be
 UTC, and it outputs a Local time string."


 Ahhh.  Ick.  That's a bit counter-intuitive no?

 I'd prefer timezone conversions to be restricted to the explicit calls 
 UTCtoLocalTime and LocalTimetoUTC.


 <snip>
 
 AISI the problem is that d_times can be in an arbitrary mix of time 
 zones, yet don't contain time zone information.

 My utility library
 
 http://pr.stewartsplace.org.uk/d/sutil/
 
 does it better - a DateTime or TimeValue is always stored in UTC.


Thanks.  I hope you guys sit down at/after the conference and sort out 
some sort of method by which these sorts of things can get included into 
Phobos.

Or better yet;  Walter sits down with you guys and agrees to a set of 
design guidelines for the standard library, things like:

* Use classes when state is required between function calls.
   - Otherwise, use free functions.
   - Provide an optional class wrapper.

(As D allows many different development styles a totally class based 
standard library would be wrong, but I think the rule above should keep 
both camps happy.  There may be a slight performance penalty for a class 
wrapper, maybe inlining will remove it, who knows)

It may be that once the rules are defined that Tango with few 
modifications/additions would fall within the rules.  In which case 
Phobos and Tango could be merged and one standard library produced.

This library would continue to be maintained, as Tango is, allowing 
everyone to contribute.

Well, that's my ideal world anyway.

I do however recall some fundamental disagreements over such things as 
how to handle console input/output, whether to maintain C compatibility 
etc.  I only hope that it's possible to make both sides happy, perhaps 
by splitting this part off and and linking the correct option based on 
version statements and pragmas or something.

Regan
Aug 23 2007