[M3devel] time conversion problems : Date.ToTime on AMD64_LINUX

[Jay K]

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?
e.g.

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3?rev=1.1.1.2;content-type=text%2Fplain
http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/TimePosix.m3?rev=1.1.1.1;content-type=text%2Fplain


and notice:

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/TimePosix.m3
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:
http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/Attic/DateBsd.m3?rev=1.1.1.2;content-type=text%2Fplain

  (* adjust result to reflect "d.offset" *)
    EVAL Utime.time(ADR(now));
    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)
    END;

 - Jay

> 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);
> #else
>     t = mktime(&tm);
> #endif
> #ifdef DATE_BSD
>     if (t == -1)
>         goto Exit;
> 
>     /* adjust result to reflect "date->offset" */
> #ifdef _TIME64_T
>     time64(&now);
>     local_now = localtime64(&now);
> #else
>     time(&now);
>     local_now = localtime(&now);
> #endif
>     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);
> Exit:
> #endif
>     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
> implementations.
> 
> 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.
> 
>      Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110411/15a779c0/attachment-0002.html>