www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: std.date time problem

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));

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));

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:

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

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:

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

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