<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Something went very wrong in the history here. Long ago. Not today.<BR>I think we never got the 5.1 changes out of a branch, or something.<BR>
<BR>In version 1.2 I accidentally did copy them out of the branch somehow,<BR>and then in 1.3 I put it back, since I wasn't intending to do that.<BR>I don't know how I would have gotten that content.<BR> Maybe I scrolled down in the cvsweb and selected what I thought was previous,<BR> as part of editing/reverting my work.<BR>
At the time now way I would have used cvs upd -r. I didn't learn till much later.<BR>
<BR>See<BR><A href="http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.3">http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=1.3</A><BR>
<BR>1.1 and 1.3 are identical.<BR>
<BR>
<BR>1.1 to 1.4<BR>
<A href="http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/time/POSIX/DatePosix.m3.diff?r1=1.1;r2=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</A><BR>
is the change I was after.<BR>
<BR>
<BR>That leaves me uncertain which historical behavior to aim for. :(<BR>Need to write more tests..<BR>
<BR> - Jay<BR><BR><BR><BR><BR><BR> <BR>
<HR id=stopSpelling>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com<BR>Subject: date/time stuff<BR>Date: Thu, 15 Apr 2010 12:18:44 +0000<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
I still have small lingering concerns here.<BR> <BR><BR> - when to call tzset?<BR> Historically we called at in the Posix version startup only.<BR> I believe localtime implicitcally calls tzset, so we kind of had it backwards?<BR><BR> <BR> - foo vs. foo_r?<BR> I changed any to _r. However there are differences relative, again, to tzset.<BR> It seems to me, program can be long running, can span a timezone change.<BR> Calling tzset just at startup, not great.<BR> <BR><BR> - So maybe a better approach is<BR> DisableScheduling/EnableScheduling<BR> Don't use the _r functions?<BR> and/or call tzset more often?<BR> <BR><BR> - I think I should probably introduce an "idealized" "DatePosix.T" just containing INTEGERs<BR> or LONGINTs and no subranges. Besides making the layout totally clear, unlike today,<BR> that will also cause subrange checks when the Modula-3 code copies the C values out.<BR> Today there are no subrange checks.<BR> One needs to be careful defining the ranges, due to various "leap" conditions (not just days,<BR> but also seconds, etc.)<BR> <BR><BR> - I have not run tests that span timezone changes.<BR> I think that should be done. It's not difficult actually.<BR> Just put an infinite loop around p235 and require user to press enter between iterations,<BR> meanwhile changing the system clock/timezone.<BR> I can get to that within a week.<BR> <BR><BR> - There is some possibility here of sharing implementation with Win32!<BR> ANSI C has localtime/gmtime, of course and msvcr*.dll do expose daylight, tzname[].<BR> Possibly we can have just one "Posix" implementation.<BR> Instead of today's three implementations.<BR> <BR><BR> - Jay<BR><BR> <BR>
<HR id=ecxstopSpelling>
From: jay.krell@cornell.edu<BR>To: jkrell@elego.de; m3commit@elegosoft.com<BR>Date: Thu, 15 Apr 2010 11:49:09 +0000<BR>Subject: Re: [M3commit] CVS Update: cm3<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
diff attached<BR><BR> <BR>> Date: Thu, 15 Apr 2010 13:44:28 +0000<BR>> To: m3commit@elegosoft.com<BR>> From: jkrell@elego.de<BR>> Subject: [M3commit] CVS Update: cm3<BR>> <BR>> CVSROOT: /usr/cvs<BR>> Changes by: jkrell@birch. 10/04/15 13:44:28<BR>> <BR>> Modified files:<BR>> cm3/m3-libs/m3core/src/: m3core.h <BR>> cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.m3 DatePosixC.c <BR>> TimePosix.i3 TimePosix.m3 <BR>> TimePosixC.c m3makefile <BR>> cm3/m3-libs/m3core/src/unix/: m3makefile <BR>> cm3/m3-libs/m3core/src/unix/Common/: Unix.i3 Utime.i3 UtimeC.c <BR>> Utypes.i3 <BR>> Added files:<BR>> cm3/m3-libs/m3core/src/time/POSIX/: DatePosix.i3 <BR>> <BR>> Log message:<BR>> eliminate struct_tm (somewhat platform specific)<BR>> eliminate struct_timeval (somewhat platform specific)<BR>> eliminate FDSet (somewhat platform specific)<BR>> eliminate MAX_FDSET (somewhat platform specific)<BR>> eliminate lots of functions from Utime<BR>> i.e. functions that use those types, like gettimeofday, localtime, gmtime<BR>> functions that were used only in m3core/src/time/*.m3 like get_timezone, altzone<BR>> <BR>> eliminate "all" the m3core/src/unix platform dependent directories *except*<BR>> Solaris/sparc32 (SOLgnu/SOLsun) for stack walking support<BR>> uin-common vs. uin-len<BR>> <BR>> change time_t to be 64bits for all platforms<BR>> but underlying implementation still needs work (elaborated below)<BR>> <BR>> tested on SOLgnu, AMD64_DARWIN, LINUXLIBC6<BR>> It compiles and the assertions all hold.<BR>> Local and utc data appears correct, cross checking with date and date -u, including<BR>> setting Linux/x86 and Solaris/sparc32 system clocks back to Jan 1 2010.<BR>> Did not test functionaly on Darwin or any BSD (but note that Linux uses the BSD code).<BR>> <BR>> still to do:<BR>> use 64bit time_t code from http://code.google.com/p/y2038/<BR>> combine some of lingering code in UtimeC.c into Time/DatePosixC.c, as static functions<BR>> We can actually add stuff back like localtime/gmtime trafficing in 64bit time_t,<BR>> as long as we use our own carefully controlled/copied types (i.e. omit the<BR>> extra two fields in struct tm). Just as well as we can provide gettimeofday, select. If we must.<BR>> Maybe test on Darwin, *BSD, Cygwin, Interix, etc.<BR>> Test in other timezones.<BR>> Enable a regularly run test?<BR>> Consider relayout Date.T to it doesn't have padding in the middle or perhaps anywhere.<BR>> (Hard to avoid if there are subranges, will be padded at least at end.)<BR>> <BR>> We can't achieve 64bit gettimeofday or file timestamps beyond year 2038<BR>> but if you fill in a Date.T with year > 2038, that can be useful and be made<BR>> to work. It should roundtrip with Time.T and be printable.<BR>> <BR>> structure is a little odd<BR>> DatePosix.i3, TimePosix.i3 describe C code<BR>> DatePosix.m3, TimePosix.m3 expose Date, Time, call into DatePosix, TimePosix<BR>> This is just to reuse existing names or name patterns.<BR>> We could just as well introduce new interfaes TimeC, DateC, TimeInternal, DateTimeInternal, etc.<BR>> <BR>> Note: This also fixes the UTC timezone on Solaris, Interix, HP-UX, Cygwin, which appear to have been historically broken.<BR>> <BR>> Note: This also uncovered that my Solaris clock was behind by a few minutes.<BR>> <BR> </body>
</html>