[M3devel] time conversion problems : Date.ToTime on AMD64_LINUX
jay.krell at cornell.edu
Mon Apr 11 04:00:35 CEST 2011
This stuff is tricky. Maybe impossible. And requires a fair amount of time and attention.
Which I might not have right now, but which I definitely tried to apply at the time.
Can you compare with some historical versions?
Revision 1.3: download - view: text, markup, annotated - select for diffs
Note: This also fixes the UTC timezone on Solaris, Interix, HP-UX, Cygwin, which appear to have been historically broken.
I'm usually a bit nervous when I make accusations of long-term breakage.
And yeah there is a general problem of determining when daylight savings is in effect.
The rules very often change. The operating system needs a lot of data to know this.
This stuff should be easy to debug without m3gdb.
Just print stuff to stdout liberally.
Aha, see here:
(* adjust result to reflect "d.offset" *)
local_now := Utime.localtime(ADR(now));
IF local_now.tm_isdst > 0 THEN
(* decrement the local time zone by one hour if DST is in effect *)
DEC(local_now.tm_gmtoff, 1 * SecsPerHour)
> To: m3devel at elegosoft.com; jay.krell at cornell.edu
> Date: Sun, 10 Apr 2011 15:45:16 -0700
> From: mika at async.caltech.edu
> Subject: [M3devel] time conversion problems : Date.ToTime on AMD64_LINUX
> Hello m3devel (especially Jay),
> I'm having some time conversion problems. I *believe* (a bit hard to
> verify because m3gdb isn't working!!) that Date.ToTime called on
> Jan 1 1970 in timezone "UTC" or "GMT" is returning -3600 for me.
> I note the following (fairly recent) code in DatePosixC.c:
> #ifdef _TIME64_T
> t = mktime64(&tm);
> t = mktime(&tm);
> #ifdef DATE_BSD
> if (t == -1)
> goto Exit;
> /* adjust result to reflect "date->offset" */
> #ifdef _TIME64_T
> local_now = localtime64(&now);
> local_now = localtime(&now);
> assert(local_now != NULL);
> if (local_now->tm_isdst > 0)
> /* decrement the local time zone by one hour if DST is in effect */
> local_now->m3_tm_gmtoff -= SecsPerHour;
> /* As above, we must negate "date->offset" to account for the
> opposite sense of that field compared to Unix. */
> t -= ((-date->offset) - local_now->m3_tm_gmtoff);
> return t;
> What I don't understand is the subtracting off of SecsPerHour if
> "now" is DST. Yeah, now is DST (it's April), but the time I'm
> converting was in the winter, and besides GMT and UTC don't even
> have DST.
> I don't understand the intent of the code.. can someone explain why
> we're subtracting off an hour? And why is it based on the value of
> tm_isdst of the *current* time? Some additional documentation within
> the file would be helpful too.
> Note my conversion returns the correct 0 on various other M3
> Note the system time on my system is in a timezone that has DST
> (namely, BST) but I have changed the TZ environment variable to UTC or GMT
> before calling this code.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the M3devel