- tz - lists.iana.org

Re: (SC22WG14.6158) (SC22WG14.6131) (SC22WG14.6130) Summary of problems with draft C9x <time.h>, and a proposed fix
by Canaglobe International Inc. Oct. 2, 1998

Oct. 2, 1998

The dilema noted by Clive Featherstone of a completely satisfactory technical solution versus layering on a still-not-staisfactory solution is, unfortunately, increasingly common in many standardization area particluarly those where there is a substantial sunk investment and user base in legacy systems. I would propose that one approaches the problem by (1) working on the development of a "completely satisfactory technical solution" for ALL the required functionalities and then, and in the context of (1) (2) develop interim solutions, migration strategies/paths, etc. generally as well as required for particular user bases (e.g. the MS-DOS) community In short separate (a) the totality of the needed/desirable from the (b) immediately do-able, need to recognize the reality of sunk investments. This having been recognized, mapped out and accepted, the only remaining contentious question then becomes one of time lines (pardon the pun). Trust that this is of some use - Jake Knoppers

1 0

Comments from David R Tribble on ISO C 9X time proposal
by Markus Kuhn Oct. 2, 1998

Oct. 2, 1998

Here are a number of good comments on the modernized <time.h> from an author of a related proposal, which I'd like to share with those of you interested in this project. ------- Forwarded Message Date: Tue, 22 Sep 1998 15:11:31 -0500 To: Markus Kuhn <markus.kuhn(a)cl.cam.ac.uk> From: David R Tribble <david.tribble(a)dallas.beasys.com> Subject: new time.h comments I have some comments on your new <time.h> proposal. Some of these ideas came from my original proposal concerning an extended-precision time type (which I have abandoned for the time being; the text is still available at http://www.flash.net/~dtribble/text/c0xtime.htm if you're interested). 1. I would prefer that the macro names begin with an '_' in order to keep them out of the user's identifier name space. Thus, you would have names like '_TIME_UTC', '_TIME_TAI', etc. 2. It would be nice to have the concept of an 'unknown' or 'unspecified' time. Such a value would indicate a time value that is not (yet) known or a time value that has not (yet) been set to a valid time. This could be defined as a special constant named '_TIME_UNKNOWN'. Arithmetically, this value would compare less than all other valid time values. 3. Similarly, it would be nice to have the concept of a 'never' time, i.e., a time that has not yet occurred or a point in time that will never be reached. This could also be considered as something akin to a 'maximum' time value. This could be defined as a special constant named '_TIME_NEVER'. Arithmetically, this value would compare greater than all other valid time values. 4. You have defined the ability to determine the resolution of the time type, but there is no way to determine the valid range that time values span. This could be done by defining the macros '_TIME_MIN_YEAR' and '_TIME_MAX_YEAR' which specify, respectively, the earliest year containing Jan 1 and the latest year containing Dec 31, that are representable by the time type. 5. Of the 'TIME_XXX' macros defined, only the last three (TIME_LOCAL, TIME_SYNC, and TIME_RESOLUTION) need to be disjoint bitmask values; the remaining macro values can simply be distinct numeric values (such as 1, 2, 3, 4, etc.). (Personally, I don't like constants used for commands to include a zero value; zero to me means "undefined" or "unknown".) 6. The TIME_UTC epoch is defined as starting at 1970-01-01, but has no well-defined value until after 1972-01-01. Why not just define the epoch as beginning at 1972-01-01? 7. By the same token, the TIME_TAI epoch is defined as starting as 1970-01-01 but has no well-defined values until after 1972-01-01. Why not just start the epoch at 1972-01-01? 8. You need to be careful that, when describing the TIME_TAI epoch and times reckoned within that epoch, that you do not imply that such reckoning *requires* accuracy to external TAI time sources (i.e., make it clear that synchronization with outside time counters is purely optional.) Some people might misinterpret this as an implied requirement, and use it as justification to ignore your proposal. 9. The flaw with the TIME_TAI representation is that, even though single leap seconds are taken into account in the encoding, the difference between two TAI times does not properly account for the true number of leap seconds between them. Perhaps a function should exist for the sole purpose of deriving the difference between two (TAI) times which does take into account all intervening leap seconds, to wit: int diffxtime(struct xtime *diff, const struct xtime *a, const struct *xtime b); Fills in '*diff' with the difference between 'a' and 'b'. Returns i<0 if 'a' is before 'b', or i>0 if 'a' is after 'b', else 0. Perhaps an 'int clock_type' argument is needed, too. 10. The TIME_MONOTONIC epoch is defined as beginning at the last system reset. Some systems are not capable of discerning time this way, and can only reckon time from the start of the current process. Indeed, the standard clock() function is defined with this in mind. Perhaps the TIME_MONOTONIC epoch should be defined similarly. 11. TIME_PROCESS and TIME_THREAD fill a definite need, a la the times() call of POSIX. However, there is no way to ascertain the total elapsed CPU time for *child* processes. Perhaps a TIME_PROCESS_CHILDREN? 12. There ought to be a way to retrieve information for the local timezone. The definition of tz_prep() states that a null argument returns information about "some externally defined default timezone". A better definition would return information about "the local timezone, possibly determined from some external source (such as the program execution environment)". Alternatively, another function could be defined for the sole purpose of retrieving the local timezone information, such as: int tz_local(timezone_t *tz); 13. The calling convention to tz_prep() could be made better, to wit: int tz_prep(timezone_t *tz, const char *restrict tzstring); On success, the function shall set the contents of the object pointed to by 'tz' with the appropriate timezone information. This is better because tz_prep() does not then need to allocate any memory (it is allocated by the caller instead). This means that tz_free() is not needed. AFAIK, no standard library functions explicitly allocate memory, and the ISO committee has tried in the past to avoid inventing functions that do so. 14. The xtime_breakup() function ignores xtp->nsec, which is a shame. As I have suggested in other postings and in my proposal, it would be nice to have access to subsecond precision in the 'tm' structure, but this poses a problem with binary compatibility with existing code. What we are left with, then, is the need to access both the broken-down 'tm' structure and the original xtime value, so that we have access to the full time information. (On a tangent note, I don't like the name; perhaps something like xtime_split() or xtime_expand()?) 15. Similarly (as I have suggested previously), strftime() and strxftime() should contain a format specifier for fractional seconds (subseconds). Your proposal provides this ability. An alternative approach would be to add conversion specifiers for getting at the subseconds, such as: %q milliseconds (3 digits, not rounded) %Q microseconds (6 digits, not rounded) etc. (If conversion size specifiers are added, we would only need one specifier letter.) 16. In spite of your desire to obsolete the time_t type, we will still need a way of converting between xtime and time_t types, if for no other reason than for providing a smoother transition away from time_t. Without explicit conversion functions, the only alternative is to convert by first converting to struct 'tm' values, which seems unnecessarily wasteful. 17. I agree that the 'tmx' structure, with its tm_ext member, is an ill-conceived invention by the ISO committee. There ought to be a better way to allow for future extentions without the need for an extra allocation area. How this chunk is allocated, deallocated, and passed to other functions is never discussed in the draft. 18. You are slightly incorrect about Microsoft using a float type for time_t; they use a 32-bit signed binary integer identical to the POSIX time_t type. Apple's Rhapsody O/S, however, uses a 'double' for times and intervals. 19. Minor typos: 1.2.1, xtime_get(), "Returns": <If time != NULL then> should be <If xtp != NULL then>. 1.4.4, strfxtime(), "Description": <full stop> should be <period>; <decimal dot or decimal comma> should be <decimal-point period or comma>, see wording in [7.11.2.1 localeconv()] for consistency. 2, Rationale, "Lack of control over timezone": <proofed> should be <proved>. 2, Rationale, "POSIX and BSD predecessors": <problematic> should be <problem>. One final suggestion, pertaining to your choice of representation for the xtime type: You might want to consider implementing the xtime type as a 64-bit signed binary integer value instead of a structure. Either 'long long int' or 'int_least64_t' would be appropriate, with the value of a given time t is: t = (sec x 2 x 10^6) + usec + (Lsec x 10^6) where 'sec' is the number of seconds since the start of the epoch, 'usec' is the number of microseconds since that second, and 'Lsec' is 1 if a leap second is present, otherwise it is 0. This encoding seems to accomplish the same goals as your xtime structure, with the advantage that, since it is a simple arithmetic type, computations can be performed on it more efficiently. And it is smaller than the structure (64 bits wide instead of 96). These make it more amenable for directly storing it in binary data files and transmitting across networks. Even though it has less high bits, it is still capable of representing time to the nearest microsecond across a range of over 146,000 years (BC73000 to AD73000), which should be quite sufficient for most applications. The only real difference between this type and your xtime type is the resolution; I think that microsecond precision would be useful for most applications. (Of course, we could push the resolution up by a factor of ten, encoding 100 nsec ticks instead of usecs, which would reduce the range down to BC7300-AD7300, or BC4713-AD9900.) I hope these comments help. I, too, am quite serious about getting a useful and "correct" set of time/date functions into the new C9X standard. I am in the process of feeding my suggestion to Clive Feather, who has expressed an interest in collecting such comments and rewriting section 7.23 of the C9X draft. --------------------. +1-972-738-6125 Work ,-. C++: the PL/1 of David R. Tribble \ ,---------------------' \ the 90s http://www.beasys.com `-' +1-972-738-6111 Fax `------------------- dtribble(a)technologist.com http://www.flash.net/~dtribble Support the anti-Spam amendment, join at http://www.cauce.org/ ------- End of Forwarded Message

2 1

Re: (SC22WG14.6158) (SC22WG14.6131) (SC22WG14.6130) Summary of problems with draft C9x <time.h>, and a proposed fix
by Clive D.W. Feather Oct. 2, 1998

Oct. 2, 1998

Douglas A. Gwyn (IST) said: > I think we need to poll the voting members to determine whether > anybody insists on having struct tmx in C9x. If not, since there > has been some formal objection to it, backing out the struct tmx > related changes seems like an appropriate way to respond to > (adverse) public comment. > > Personally I'd rather see a completely satisfactory technical > solution than layering on a still-not-satisfactory solution. > Since I doubt the former can be done within the C9x schedule, > leaving <time.h> pretty much the way it was in C89 seems proper. I'm not happy with <time.h> as it is, but I'm a lot unhappier with the C89 version, and I don't like the proposals that Marcus Kuhn is writing either (I need to talk to him face-to-face about this). I would object, and would ask the UK to object, to any proposal that removes the new functionality without a good replacement. I will try to write this up more clearly when I find the time, but it probably won't be in the next week. -- Clive D.W. Feather | Work: <clive(a)linx.org> | Tel: +44 1733 705000 Regulation Officer | or: <clive(a)demon.net> | or: +44 973 377646 London Internet Exchange | Home: <clive(a)davros.org> | Fax: +44 1733 353929 (on secondment from Demon Internet)

1 0

Re: Modernized <time.h> for ISO C 9X
by Markus Kuhn Oct. 2, 1998

Oct. 2, 1998

Marc Brett wrote on 1998-09-18 12:09 UTC: > There have been discussions here before to the effect that TAI is the > One True Time and all systems should be based around it. This neglects > the fact that most of the world runs to UTC not TAI, and that the > maintenance of the TAI-UTC offset on all machines is an impossible > expectation. Your proposal has an important merit in that TAI-UTC > tables are not strictly necessary. > > Good luck getting this through! Thanks for your comments. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>

1 0

tzcode1998h.tar.gz and tzdata1998i.tar.gz
by Olson, Arthur David (NCI) Oct. 1, 1998

Oct. 1, 1998

The files ftp://elsie.nci.nih.gov/pub/tzcode1998h.tar.gz and ftp://elsie.nci.nih.gov/pub/tzdata1998h.tar.gz are now available. These incorporate the changes for Brazil, Chile, and Germany circulated on the time zone mailing list earlier this week; also included is support for use of "24:00" in the input files for the time zone compiler. --ado

1 0

proposed changes for Chile, Brazil, historical time in Germany, etc.
by Paul Eggert Sept. 29, 1998

Sept. 29, 1998

Here are some more proposed changes to the tz data. The Chilean and Brazilian changes are relatively urgent, so I thought I'd send this out now. * Chile started observing DST this year on 09-26, due the the drought. Thanks to Ian Tragen for informing us of this, and to Eduardo Krell for providing the details. * Brazil's 1998/1998 transitions will differ the values predicted in the current tz data; I sent out a draft of this change earlier. Thanks to Marcos Tadeu for the info and pointers. * Adjust some historical data for Germany in 1945 and 1946 to better match the data at the official German web site for DST. Also, change the suffix for continental-Europe double summer time from DST to MT (Midsummer Time), as per the PDB. Thanks to Markus Kuhn for the pointer to this info. =================================================================== RCS file: RCS/southamerica,v retrieving revision 1998.8 retrieving revision 1998.8.0.4 diff -u -r1998.8 -r1998.8.0.4 --- southamerica 1998/09/24 14:46:11 1998.8 +++ southamerica 1998/09/29 19:46:53 1998.8.0.4 @@ -184,14 +184,6 @@ # Brazil -# From Guy Harris: -# The OAG lists 1987-10-25 and 1988-02-12 as the starting and -# ending dates, giving them as "estimated date(s) based on previous year". We -# infer a rule here from one example, always a dangerous practice.... Yes, -# they really do switch on Saturday, according to the OAG. -# "[America/Porto_Acre]" is for the [State] of Acre; -# "[America/Noronha]" is for Fernando De Noronha. - # From Paul Eggert <eggert(a)twinsun.com> (1993-11-18): # The mayor of Rio recently attempted to change the time zone rules # just in his city, in order to leave more summer time for the tourist trade. @@ -247,33 +239,78 @@ # error. Line 193 say "Territory of Acre". It is not a territory anymore # but a state. +# From Marcos Tadeu (1998-09-27): +# <a href="http://pcdsh01.on.br/verao1.html"> +# Brazilian official page +# </a> +# +# From Paul Eggert (1998-09-28): +# The official decrees referenced below are taken from +# <a href="http://pcdsh01.on.br/DecHV.html"> +# Decretos sobre o Horario de Verao no Brasil +# </a> (1998-09-25, in Portuguese). +# I don't read Portuguese, and haven't been able to verify them against +# the Shanks and IATA data; there do seem to be minor discrepancies. + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S +# Decree <a href="http://pcdsh01.on.br/HV20466.htm">20.466</a> (1931-01-10) +# Decree <a href="http://pcdsh01.on.br/HV21896.htm">21.896</a> (1932-01-10) Rule Brazil 1931 only - Oct 3 11:00 1:00 D Rule Brazil 1932 1933 - Apr 1 0:00 0 S Rule Brazil 1932 only - Oct 3 0:00 1:00 D +# Decree <a href="http://pcdsh01.on.br/HV23195.htm">23.195</a> (1933-10-10) +# revoked DST. +# Decree <a href="http://pcdsh01.on.br/HV27496.htm">27.496</a> (1949-11-24) +# Decree <a href="http://pcdsh01.on.br/HV27998.htm">27.998</a> (1950-04-13) +# Decree <a href="http://pcdsh01.on.br/HV32308.htm">32.308</a> (1953-02-24) Rule Brazil 1949 1952 - Dec 1 0:00 1:00 D Rule Brazil 1950 only - Apr 16 0:00 0 S Rule Brazil 1951 1953 - Apr 1 0:00 0 S +# Decree <a href="http://pcdsh01.on.br/HV34724.htm">34.724</a> (1953-11-30) +# revoked DST. +# Decree <a href="http://pcdsh01.on.br/HV52700.htm">52.700</a> (1963-10-18) +# Decree <a href="http://pcdsh01.on.br/HV53071.htm">53.071</a> (1963-12-03) Rule Brazil 1963 only - Dec 9 0:00 1:00 D +# Decree <a href="http://pcdsh01.on.br/HV53604.htm">53.604</a> (1964-02-25) Rule Brazil 1964 only - Mar 1 0:00 0 S +# Decree <a href="http://pcdsh01.on.br/HV55639.htm">55.639</a> (1965-01-27) Rule Brazil 1965 only - Jan 31 0:00 1:00 D Rule Brazil 1965 only - Apr 1 0:00 0 S +# Decree <a href="http://pcdsh01.on.br/HV57303.htm">57.303</a> (1965-11-22) Rule Brazil 1965 only - Dec 1 0:00 1:00 D +# Decree <a href="http://pcdsh01.on.br/HV57843.htm">57.843</a> (1966-02-18) Rule Brazil 1966 1968 - Mar 1 0:00 0 S Rule Brazil 1966 1967 - Nov 1 0:00 1:00 D +# Decree <a href="http://pcdsh01.on.br/HV63429.htm">63.429</a> (1968-10-15) +# Decree <a href="http://pcdsh01.on.br/HV91698.htm">91.698</a> (1985-09-27) Rule Brazil 1985 only - Nov 2 0:00 1:00 D +# Decree 92.310 (1986-01-21) +# Decree 92.463 (1986-03-13) Rule Brazil 1986 only - Mar 15 0:00 0 S +# Decree 93.316 (1986-10-01) +# Decree <a href="http://pcdsh01.on.br/HV94922.htm">94.922</a> (1987-09-22) Rule Brazil 1986 1987 - Oct Sat<=28 0:00 1:00 D Rule Brazil 1987 only - Feb 14 0:00 0 S Rule Brazil 1988 only - Feb 7 0:00 0 S +# Decree <a href="http://pcdsh01.on.br/HV96676.htm">96.676</a> (1988-09-12) +# Decree <a href="http://pcdsh01.on.br/HV98077.htm">98.077</a> (1989-08-21) +# Decree <a href="http://pcdsh01.on.br/HV99530.htm">99.530</a> (1990-09-17) +# Decree 99.629 (1990-10-19) +# <a href="http://pcdsh01.on.br/HV1991.htm">Unnumbered decree</a> (1991-09-25): +# <a href="http://pcdsh01.on.br/HV1992.htm">Unnumbered decree</a> (1992-10-16): Rule Brazil 1989 only - Jan 22 0:00 0 S Rule Brazil 1988 1989 - Oct Sun>=10 0:00 1:00 D Rule Brazil 1990 1991 - Feb Sun>=11 0:00 0 S Rule Brazil 1990 1992 - Oct Sun>=20 0:00 1:00 D Rule Brazil 1992 only - Feb 9 0:00 0 S +# Decree <a href="http://pcdsh01.on.br/HV942.htm">942</a> (1993-09-28) +# Decree <a href="http://pcdsh01.on.br/HV1252.htm">1.252</a> (1994-09-22) +# Decree <a href="http://pcdsh01.on.br/HV1636.htm">1.636</a> (1995-09-14) +# Decree <a href="http://pcdsh01.on.br/HV1674.htm">1.674</a> (1995-10-13) Rule Brazil 1993 1995 - Oct Sun>=11 0:00 1:00 D Rule Brazil 1993 only - Jan 31 0:00 0 S Rule Brazil 1994 1995 - Feb Sun>=15 0:00 0 S +# Decree <a href="http://pcdsh01.on.br/HV2000.htm">2.000</a> (1996-09-04) Rule Brazil 1996 only - Feb Sun>=11 0:00 0 S Rule Brazil 1996 only - Oct Sun>=1 0:00 1:00 D # From Daniel C. Sobral <dcs(a)gns.com.br> (1998-02-12): @@ -284,15 +321,23 @@ # to help dealing with the shortages of electric power. # # From Paul Eggert (1998-02-25): -# Reference for 1997-10-06 change: # <a href="http://churchnet.ucsm.ac.uk/news/files2/news165.htm"> # Brazil Prepares for Papal Visit # </a>, # Church Net UK (1997-10-02). +# +# Decree 2.317 (1997-09-04) Rule Brazil 1997 only - Oct 6 0:00 1:00 D +# Decree <a href="http://pcdsh01.on.br/figuras/HV2495.JPG">2.495</a> +# (1998-02-10) Rule Brazil 1998 only - Mar 1 0:00 0 S -Rule Brazil 1998 max - Oct Sun>=1 0:00 1:00 D -Rule Brazil 1999 max - Feb Sun>=11 0:00 0 S +# Decree <a href="http://pcdsh01.on.br/figuras/Hv98.jpg">2.780</a> (1998-09-11) +# specifies only the 1998-10-11 and 1999-02-21 transitions; +# after that, these rules are guesses and are quite possibly wrong, +# but they are more likely than no DST at all. +Rule Brazil 1998 max - Oct Sun>=11 0:00 1:00 D +Rule Brazil 1999 max - Feb Sun>=15 0:00 0 S + # Zone NAME GMTOFF RULES FORMAT [UNTIL] # @@ -349,14 +394,20 @@ # From Eduardo Krell (1995-10-19): # The law says to switch to DST at midnight [24:00] on the second SATURDAY # of October.... The law is the same for March and October. +# (1998-09-29): +# Because of the drought this year, the government decided to go into +# DST earlier (saturday 9/26 at 24:00). This is a one-time change only ... +# (unless there's another dry season next year, I guess). # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Chile 1918 only - Sep 1 0:00 1:00 S Rule Chile 1919 only - Jul 2 0:00 0 - Rule Chile 1927 1931 - Sep 1 0:00 1:00 S Rule Chile 1928 1932 - Apr 1 0:00 0 - -Rule Chile 1969 max - Oct Sun>=9 0:00 1:00 S +Rule Chile 1969 1997 - Oct Sun>=9 0:00 1:00 S Rule Chile 1970 max - Mar Sun>=9 0:00 0 - +Rule Chile 1998 only - Sep 27 0:00 1:00 S +Rule Chile 1999 max - Oct Sun>=9 0:00 1:00 S # IATA SSIM anomalies: (1990-09) says 1990-09-16; (1992-02) says 1992-03-14; # (1996-09) says 1998-03-08. Ignore these for now. # Zone NAME GMTOFF RULES FORMAT [UNTIL] =================================================================== RCS file: RCS/europe,v retrieving revision 1998.8 retrieving revision 1998.8.0.1 diff -u -r1998.8 -r1998.8.0.1 --- europe 1998/09/24 14:46:11 1998.8 +++ europe 1998/09/29 19:47:13 1998.8.0.1 @@ -948,7 +948,7 @@ # Shanks gives 1921 Mar 21 for the following transition. # From Andrey A. Chernov <ache(a)astral.msk.su> (1993-11-12): # My sources says, that it is Mar 20, not 21. -Rule Russia 1921 only - Mar 20 23:00 2:00 DS +Rule Russia 1921 only - Mar 20 23:00 2:00 M # Midsummer Rule Russia 1921 only - Sep 1 0:00 1:00 S Rule Russia 1921 only - Oct 1 0:00 0 - # Act No.925 of the Council of Ministers of the USSR (1980-10-24): @@ -1313,19 +1313,19 @@ Rule France 1940 only - Feb 25 2:00 1:00 S # The French rules for 1941-1944 were not used in Paris, # but were used in other places (e.g. Monaco). -Rule France 1941 only - May 5 0:00 2:00 DS +Rule France 1941 only - May 5 0:00 2:00 M # Midsummer # Shanks says this transition occurred at Oct 6 1:00, # but go with Denis.Excoffier(a)ens.fr (1997-12-12), # who quotes the Ephemerides Astronomiques for 1998 from Bureau des Longitudes # as saying 5/10/41 22hUT. Rule France 1941 only - Oct 6 0:00 1:00 S -Rule France 1942 only - Mar 9 0:00 2:00 DS +Rule France 1942 only - Mar 9 0:00 2:00 M Rule France 1942 only - Nov 2 3:00 1:00 S -Rule France 1943 only - Mar 29 2:00 2:00 DS +Rule France 1943 only - Mar 29 2:00 2:00 M Rule France 1943 only - Oct 4 3:00 1:00 S -Rule France 1944 only - Apr 3 2:00 2:00 DS +Rule France 1944 only - Apr 3 2:00 2:00 M Rule France 1944 only - Oct 8 1:00 1:00 S -Rule France 1945 only - Apr 2 2:00 2:00 DS +Rule France 1945 only - Apr 2 2:00 2:00 M Rule France 1945 only - Sep 16 3:00 0 - # Shanks gives Mar 28 2:00 and Sep 26 3:00; # go with Excoffier's 28/3/76 0hUT and 25/9/76 23hUT. @@ -1347,16 +1347,30 @@ # Germany +# From Markus Kuhn <Markus.Kuhn(a)cl.cam.ac.uk> (1998-09-29): +# The German time zone web site by the Physikalisch-Technische +# Bundesanstalt contains DST information back to 1916. +# +# <a href="http://www.ptb.de/english/org/4/43/432/lega.htm"> +# Realisation of Legal Time in Germany +# </a> + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Germany 1945 only - Apr 2 2:00s 1:00 S -Rule Germany 1945 only - May 24 2:00 2:00 DS -Rule Germany 1945 only - Sep 24 3:00 1:00 S +# Shanks says 05-24 2:00 to 09-24 3:00 for DDST; go with the PTB, who quotes +# the Archiv fuer publizist. Arbeit (Munzinger-Archiv) 652 (Zeitsystem) +# (1961-11-25), which gives dates only. Guess 3:00 transition times. +Rule Germany 1945 only - May 31 3:00 2:00 M # Midsummer +Rule Germany 1945 only - Sep 23 3:00 1:00 S Rule Germany 1945 only - Nov 18 2:00s 0 - Rule Germany 1946 only - Apr 14 2:00s 1:00 S -# Whitman gives 1948 Oct 31; go with Shanks. -Rule Germany 1946 1949 - Oct Sun>=1 2:00s 0 - +# Shanks gives 1946-10-06; go with the PTB. +Rule Germany 1946 only - Oct 7 2:00s 0 - +Rule Germany 1947 1949 - Oct Sun>=1 2:00s 0 - Rule Germany 1947 only - Apr 6 2:00s 1:00 S -Rule Germany 1947 only - May 11 2:00s 2:00 DS +# The PTB gives 3:00 CET and 3:00 CEST for the midsummer transition times; +# go with Shanks. +Rule Germany 1947 only - May 11 2:00s 2:00 M Rule Germany 1947 only - Jun 29 3:00 1:00 S Rule Germany 1948 only - Apr 18 2:00s 1:00 S Rule Germany 1949 only - Apr 10 2:00s 1:00 S @@ -1898,12 +1912,12 @@ Rule Port 1940 1941 - Oct 5 23:00s 0 - Rule Port 1941 only - Apr 5 23:00s 1:00 S Rule Port 1942 1945 - Mar Sat>=8 23:00s 1:00 S -Rule Port 1942 only - Apr 25 22:00s 2:00 DS +Rule Port 1942 only - Apr 25 22:00s 2:00 M # Midsummer Rule Port 1942 only - Aug 15 22:00s 1:00 S Rule Port 1942 1945 - Oct Sat>=24 23:00s 0 - -Rule Port 1943 only - Apr 17 22:00s 2:00 DS +Rule Port 1943 only - Apr 17 22:00s 2:00 M Rule Port 1943 1945 - Aug Sat>=25 22:00s 1:00 S -Rule Port 1944 1945 - Apr Sat>=21 22:00s 2:00 DS +Rule Port 1944 1945 - Apr Sat>=21 22:00s 2:00 M Rule Port 1946 only - Apr Sat>=1 23:00s 1:00 S Rule Port 1946 only - Oct Sat>=1 23:00s 0 - Rule Port 1947 1949 - Apr Sun>=1 2:00s 1:00 S @@ -2115,9 +2129,9 @@ Rule Spain 1939 only - Apr 15 23:00s 1:00 S Rule Spain 1940 only - Mar 16 23:00s 1:00 S # Whitman says no DST 1942-1945; go with Shanks. -Rule Spain 1942 only - May 2 22:00s 2:00 DS +Rule Spain 1942 only - May 2 22:00s 2:00 M # Midsummer Rule Spain 1942 only - Sep 1 22:00s 1:00 S -Rule Spain 1943 1946 - Apr Sat>=13 22:00s 2:00 DS +Rule Spain 1943 1946 - Apr Sat>=13 22:00s 2:00 M Rule Spain 1943 only - Oct 3 22:00s 1:00 S Rule Spain 1944 only - Oct 10 22:00s 1:00 S Rule Spain 1945 only - Sep 30 1:00 1:00 S

1 0

Official German Time Web Site
by Markus Kuhn Sept. 29, 1998

Sept. 29, 1998

Brazil is not the only country with an official time zone web site. The German time zone web site by the Physikalisch-Technische Bundesanstalt contains DST information back to 1916. http://www.ptb.de/english/org/4/43/432/sumo.htm http://www.ptb.de/english/org/4/43/432/sumn.htm http://www.ptb.de/english/org/4/43/432/lega.htm Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>

1 0

Names in time.h C extension
by Markus Kuhn Sept. 29, 1998

Sept. 29, 1998

Thanks for the many comments that I have received on the modernized <time.h> C API on http://www.cl.cam.ac.uk/~mgk25/c-time/ I'll try to respond to every comment individually, but there issue that I'd like to address first separately: the names of the new elements. Almost half of all comments that I received suggested that the current namespace use of struct xtime xtime_*() strfxtime() TIME_* be changed into something else. I received numerous alternative proposals, and the only common thing among them was that they were almost all different. Most of the criticism seemed to have been just a matter of taste and not based on technical superiority of the alternative. The individual proposals were: Paul Eggert: xtime -> stime (short for "standard time", no rationale given) Nathan Myers: xtime_format: "To plan or arrange in a specified form" xtime_compose: "To make or create by putting together parts or elements." xtime_resolve: "To separate (something) into constituent parts." Ken Pizzini: timex "There is an old tradition of language design that the language and its libraries strongly avoid using identifiers starting with the letter 'x' --- a desperate application writer can then blithely prepenend an 'x' to all its first-choice identifiers and be safe." John Hauser: xtime_sleep, xtime_pack, xtime_unpack Jake Knoppers: timex "I would recommend using the term 'timex'. It is a invented term, a.k.a. coined term or neoligism, to which can be attached the apprpriate definition as well as a note at the end of such defintion of ' Formerly known as xtime'. 'Time' as word is used with multiple meanings and its use can quickly become confusing and inadvertently may have unforeseen results. Having the x precede the _resolves the ambiguity resulting from the x after _ ." Ken Pizzini: lists moment, instant, beat, clock, chronos, tiempo, heure, favours chronos Antoine Leca: chronos is better than timex or xtime (without explanation) Ok, here my reply: How did I get to xtime? Well, the original type was called time_t and I wanted to stay as close as possible to the traditional naming scheme of the C API. So I removed the _t, because this is inappropriate for a struct name. Now I had a collision with time(). My new type was an "extended time", as it had extended range, extended resolution, and a leap second extention, so for me xtime for "extendted time type" was a very obvious and nearby choice. While reviewing the comments, I haven't found a convincing reason why any of the other name proposals are better. Many of them are definitely worse. Some points I want to mention are: - Since this type is both used for clock values and for time intervals, "time" seems to me a much more appropriate base term than anything based on "clock". The clock_* namespace is already reserved for POSIX.1. - The C API is completely based on the English language, introducing terms from other languages as Antoine proposed (chronos) would certainly break some tradition. - I have never run into the "old tradition" that Ken Pizzini mentioned of programming languages reserving x prefixes for application variables. Do you have a formal reference for this, especially for the C language. The thought that it is good practice to start all your application identifiers with "x" sounds quite bizarre to me. I am not too concerned about remote chances of name collisions with a small number of applications, as there are many simple tools out there to automatically replace identifiers in software. - the type can also be used for many things that can be described as non-standard times (TIME_MONOTONIC comes to mind), therefore I don't see at all the special appeal of stime (for "standard time"). - I was surprised that suggestions that I had expected were not made: mkxtime would follow closer the traditional naming (as I did with strfxtime), and the traditional C API does not use underscores inside words (I was more influenced by POSIX.1b "tradition" here) anyway. Nathan Myers' proposal xtime_format instead of strfxtime goes even in the opposite direction, imitating more OO-style naming conventions instead of preserving the old style. I'd leave these ambitions to those who write the Python, Ada, Java, and C++ bindings for these functions. - I used "delay" instead of "sleep" only because I feel that sleep implies that the process is suspended or that the processor is put into a sleep mode, while delay does not imply any such implementation detail. There is some tradition for sleep in the sleep and nanosleep POSIX system calls, but I felt that an OS-independent programming language should not imply implementation details such as sending the process into a sleep state. Therefore I considered the Ada and Turbo Pascal "delay" statements to be closer related and more appropriate as a source for the name. - xtime_pack and xtime_unpack has for me at least a very different connotation. For me, packing and unpacking sounds more like shuffling bits around into a more compact arrangement (analog to say Ada's "packed arrays"), and does not imply the application of time zone algorithms, etc. C programmers are familiar with mktime, so "make" seemed to me much more intuitive. The struct tm representation is referred to in the standard as a broken-down time format, therefore something based on breakup seemed to me the closest and most obvious choice for the name of the inverse function of "make". The existing practice of localtime() and gmtime() is not useful here, as the name there was completely based on the specific time zone. Frankly, I don't care at all about the names, I am much more interested in the functionality, but I am also not convinced why any of the alternative proposals I have seen so far is better than what we have at the moment. Therefore, I haven't changed anything here yet. The committee is probably anyway going to rediscuss this issue, no matter what we submit ... ;-) Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>

1 0

RE: daylight-saving time in Egypt; problem with zic and `24:00'
by Olson, Arthur David (NCI) Sept. 29, 1998

Sept. 29, 1998

...unfortunately, `zic' does not let you enter the transition time `24:00', meaning midnight at the end of the day; it complains `invalid time of day'. `zic' should probably be enhanced to allow 24:00, as that is often what the rules actually say -- Egypt is an example of this.... Here's a proposed patch for zic.c to explicitly allow 24:00 (or 24:00:00); certainly if it gets used in data files such as "africa", a comment about the potential need for downloading a new time zone compiler might be placed near the scene of the crime. --ado *** 7.94/zic.c Mon Sep 28 23:11:25 1998 --- 7.95/zic.c Mon Sep 28 23:11:26 1998 *************** *** 1,6 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)zic.c 7.94"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 1,6 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)zic.c 7.95"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 901,909 **** error(errstring); return 0; } ! if (hh < 0 || hh >= HOURSPERDAY || mm < 0 || mm >= MINSPERHOUR || ! ss < 0 || ss > SECSPERMIN) { error(errstring); return 0; } --- 901,910 ---- error(errstring); return 0; } ! if ((hh < 0 || hh >= HOURSPERDAY || mm < 0 || mm >= MINSPERHOUR || ! ss < 0 || ss > SECSPERMIN) && ! !(hh == HOURSPERDAY && mm == 0 && ss == 0)) { error(errstring); return 0; }

1 0

FW: Early DST for Chile?
by Olson, Arthur David (NCI) Sept. 29, 1998

Sept. 29, 1998

-----Original Message----- From: Ian Tragen [SMTP:ian@mirage1.u-net.com] Sent: Monday, September 28, 1998 3:38 PM To: 'tz' Subject: Early DST for Chile? I am informed that Chile changed to DST earlier than usual on Sunday 27th Sept. this year. Ian Tragen Mirage Audio Visual Media web site: http://www.mirage1.u-net.com =============================

1 0