[M3devel] date/time stuff

Thu Apr 15 15:47:03 CEST 2010

Something went very wrong in the history here. Long ago. Not today.
I think we never got the 5.1 changes out of a branch, or something.

In version 1.2 I accidentally did copy them out of the branch somehow,
and then in 1.3 I put it back, since I wasn't intending to do that.
I don't know how I would have gotten that content.
  Maybe I scrolled down in the cvsweb and selected what I thought was previous,
  as part of editing/reverting my work.

  At the time now way I would have used cvs upd -r. I didn't learn till much later.

See
http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.3

1.1 and 1.3 are identical.

1.1 to 1.4

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.4

is the change I was after.

That leaves me uncertain which historical behavior to aim for. :(
Need to write more tests..

 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: date/time stuff
Date: Thu, 15 Apr 2010 12:18:44 +0000

I still have small lingering concerns here.

 - when to call tzset?
  Historically we called at in the Posix version startup only.
  I believe localtime implicitcally calls tzset, so we kind of had it backwards?

 - foo vs. foo_r?
   I changed any to _r. However there are differences relative, again, to tzset.
   It seems to me, program can be long running, can span a timezone change.
   Calling tzset just at startup, not great.

 - So maybe a better approach is
   DisableScheduling/EnableScheduling
   Don't use the _r functions?
   and/or call tzset more often?

 - I think I should probably introduce an "idealized" "DatePosix.T" just containing INTEGERs
   or LONGINTs and no subranges. Besides making the layout totally clear, unlike today,
   that will also cause subrange checks when the Modula-3 code copies the C values out.
   Today there are no subrange checks.
   One needs to be careful defining the ranges, due to various "leap" conditions (not just days,
   but also seconds, etc.)

 - I have not run tests that span timezone changes.
   I think that should be done. It's not difficult actually.
   Just put an infinite loop around p235 and require user to press enter between iterations,
   meanwhile changing the system clock/timezone.
   I can get to that within a week.

 - There is some possibility here of sharing implementation with Win32!
   ANSI C has localtime/gmtime, of course and msvcr*.dll do expose daylight, tzname[].
   Possibly we can have just one "Posix" implementation.
   Instead of today's three implementations.

 - Jay

From: jay.krell at cornell.edu
To: jkrell at elego.de; m3commit at elegosoft.com
Date: Thu, 15 Apr 2010 11:49:09 +0000
Subject: Re: [M3commit] CVS Update: cm3

diff attached

> Date: Thu, 15 Apr 2010 13:44:28 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/04/15 13:44:28
> 
> Modified files:
> cm3/m3-libs/m3core/src/: m3core.h 
> cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 DatePosixC.c 
> TimePosix.i3 TimePosix.m3 
> TimePosixC.c m3makefile 
> cm3/m3-libs/m3core/src/unix/: m3makefile 
> cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utime.i3 UtimeC.c 
> Utypes.i3 
> Added files:
> cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.i3 
> 
> Log message:
> eliminate struct_tm (somewhat platform specific)
> eliminate struct_timeval (somewhat platform specific)
> eliminate FDSet (somewhat platform specific)
> eliminate MAX_FDSET (somewhat platform specific)
> eliminate lots of functions from Utime
> i.e. functions that use those types, like gettimeofday, localtime, gmtime
> functions that were used only in m3core/src/time/*.m3 like get_timezone, altzone
> 
> eliminate "all" the m3core/src/unix platform dependent directories *except*
> Solaris/sparc32 (SOLgnu/SOLsun) for stack walking support
> uin-common vs. uin-len
> 
> change time_t to be 64bits for all platforms
> but underlying implementation still needs work (elaborated below)
> 
> tested on SOLgnu, AMD64_DARWIN, LINUXLIBC6
> It compiles and the assertions all hold.
> Local and utc data appears correct, cross checking with date and date -u, including
> setting Linux/x86 and Solaris/sparc32 system clocks back to Jan 1 2010.
> Did not test functionaly on Darwin or any BSD (but note that Linux uses the BSD code).
> 
> still to do:
> use 64bit time_t code from http://code.google.com/p/y2038/
> combine some of lingering code in UtimeC.c into Time/DatePosixC.c, as static functions
> We can actually add stuff back like localtime/gmtime trafficing in 64bit time_t,
> as long as we use our own carefully controlled/copied types (i.e. omit the
> extra two fields in struct tm). Just as well as we can provide gettimeofday, select. If we must.
> Maybe test on Darwin, *BSD, Cygwin, Interix, etc.
> Test in other timezones.
> Enable a regularly run test?
> Consider relayout Date.T to it doesn't have padding in the middle or perhaps anywhere.
> (Hard to avoid if there are subranges, will be padded at least at end.)
> 
> We can't achieve 64bit gettimeofday or file timestamps beyond year 2038
> but if you fill in a Date.T with year > 2038, that can be useful and be made
> to work. It should roundtrip with Time.T and be printable.
> 
> structure is a little odd
> DatePosix.i3, TimePosix.i3 describe C code
> DatePosix.m3, TimePosix.m3 expose Date, Time, call into DatePosix, TimePosix
> This is just to reuse existing names or name patterns.
> We could just as well introduce new interfaes TimeC, DateC, TimeInternal, DateTimeInternal, etc.
> 
> Note: This also fixes the UTC timezone on Solaris, Interix, HP-UX, Cygwin, which appear to have been historically broken.
> 
> Note: This also uncovered that my Solaris clock was behind by a few minutes.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100415/8637bd54/attachment-0002.html>