September 1998 - tz - lists.iana.org

Re: Proposal for new ISO C 9x time API
by Markus Kuhn Oct. 16, 1998

Oct. 16, 1998

Dear Timezone Gurus, I have now revised my proposal for a new <time.h> for C, which you can find on http://www.cl.cam.ac.uk/~mgk25/c-time/ When you have some time, please let me know what you think about it. Ideally we might manage to make this the basis for a proposal for ISO C9X. In case it is already too late for that, we might at least consider implementing it in the Olsen library and publish it independently (say via IETF as an RFC, or via the POSIX project). I have also added to the end of this page a pretty comprehensive list of links to online resources relevant to the topic, and a few more will come as soon as I have access to our scanner again. 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/>

9 50

Re: Proposal for new ISO C 9x time API
by Ken Pizzini Oct. 12, 1998

Oct. 12, 1998

In tz(a)elsie.nci.nih.gov message , Antoine Leca <Antoine.Leca(a)renault.fr> wrote: > > Surely we > > could think of some other, perhaps even more suitable, name > > for this? Some ideas: > > struct moment > > struct instant > > struct beat > > struct clock > > struct chronos > > struct tiempo > > struct heure ... > > (From this list, I somewhat favor "chronos".) > > Me too. > However, it may not fit well with the rest of the API, > which is clearly English-biased. Well, IMO that is largely a historical accident; since we are discussing an international standard I'm personally not too interested in enforcing that the language maintain a distinct English bias. And the Greek word chronos (Kronos) is used in English as the combinitive form "chrono-" in several words; provincial English speakers should have no problem understanding the time-related meaning of "chronos". Then again, perhaps it is better to stick with "pure English"; I don't know. > OTOH, struct time is available, too. Yes, but we still need a name to substitute for the xxx of strfxxx(), and "time" _is_ taken there. --Ken Pizzini

6 11

Re: big-picture comments on your proposed extensions to ISO C <time.h>
by Markus Kuhn Oct. 6, 1998

Oct. 6, 1998

(I hope you don't mind Paul, if I reply on tz) Paul Eggert wrote on 1998-09-29 01:34 UTC: > Here are some big-picture comments on your proposed extensions to ISO > C <time.h>. I've hacked up a copy of your HTML proposal along these > lines, if you're interested in reading it. (I still don't have a > revised rationale, though.) > > It's very hard work to come up with a good spec! After trying my hand > at it, I respect the work you've done so far; the following comments > are in the spirit of improving it to be as useful as possible. > > I have some more detailed comments once you've had time to digest > these bigger-picture comments, but first things first..... > > * Terminology proposal: let's rename `xtime' to `stime' (short for > ``standard C time''), uniformly. The rest of my discussion assumes > this new terminology. Hm, see my separate posting on the many different renaming proposals that I received. > * struct stime is inconvenient for programmers. It's hard to portably > subtract such values, much less do other arithmetic on them. Even > comparing them is error-prone. This structure's members are derived > from a similar structure in POSIX.1, but the POSIX.1 structure was > predicated on not having integer types longer than 32 bits. > > Instead, let's just use a signed integer count of the number of time > intervals since the epoch. We can define a type stime_t for this > integer, and a stime_t macro STIMES_PER_SEC giving the number of > time intervals per second. This makes time arithmetic much, much > easier. I am afraid, but I strongly disagree here. I think my current approach is more robust, functional, and therefore preferable. The reason: Most C 9X implementations will not provide any type with more than 64-bits. If we take a 64-bit type, then you can have only nanosecond resolution over an interval of 58 years. This is unacceptable; even the notorious Y2K COBOL programs fail only after 99 years. Note that this is independent of whether you use a 64-bit int or a 64-bit float type, 64-bit is just not enough for a high-resolution timestamp. About the "convenience" argument in general (and I'll come back to this for Antoine's xtime_get return value critique): Compared to modern programming languages with their variable length arrays, exceptions, garbage collectors, controlled name spaces, etc. C is and will always be a comparatively simple and quite inconvenient early-1970s language. If you want convenience, look for another language than C. The interesting thing about C these days is mostly that it is ubiquitously implemented. Most programming environments for more modern and comfortable languages are built on top of the existing C API. If you read the C++, Java, and Ada95 standards, then it becomes embarrassingly obvious that the abilities of their standard library has been limited by the existing ability of the C library, therefore is is extremely important to get the functionality of the C API right. The comfort should certainly come after functional criteria. I do not understand, why it should be difficult to portably add and subtract struct xtime values. The new <stdint.h> offer a reasonably good support here. The algorithm is trivial: Before any arithmetic, you first check whether there is a leap second in one of the arguments and abort if there is (because arithmetic is ill-defined in this case). Then you just add sec and nsec separately and adjust for the nsec overflow. Note that non-leap nsec values do not overflow the nsec type, because 2 * 1e9 < 2**31. It all fits so nicely together with nanoseconds, I couldn't think of a more appropriate representation. The POSIX.1b people made certainly a good choice here. In programming languages such as C++ or Ada where operators like "+" and "-" can be overloaded, the authors of bindings to the xtime API will certainly add the corresponding overloadings, and then xtime is as easy to use as a float type. If you insist, we could add macros or functions for struct xtime arithmetic, but I think it is better to let users do this themselves to make sure they have thought about the leap second aspects of arithmetic, which are certainly application dependent. (Again, the lack of an exception mechanism in C prevents to do a robost and comfortable interface at the same time, so we stay on the robust side and leave to comfort to languages with proper mechanics to do it.) How would you represent leap seconds in your stime_t arithmetic type? This was after all besides the resolution concerns the major reason for getting rid of time_t and its idea of using an arithmetic type. > * We should pass timestamps by value whenever possible, instead of by > reference. Passing timestamps by reference makes the program more > error-prone and (these days) slows it down. This is particularly > important for stime_get. That is an interesting point. Actually, I have never done any measurements on whether passing a 96-bit struct by reference is more efficient than passing it by value with the usual C compilers. Does anyone have any numbers on this for typical 32-bit processors? For stime_get however this is not an option: the return value is certainly required for comfortable error checking. Other programming languages with exceptions could probably return the time value here, but in C we have no exceptions and therefore (as xtime_get can fail), we will have to use it in some form of if statement with an explicit exception handler. > * We should constrain the implementation to support times through a > reasonable upper bound (e.g. 9999 AD, or perhaps something a bit > sooner since we'll have to reform our calendar well before then). > But we shouldn't insist on astronomical timescales; that places > an undue burden on the implementation. What would this burden be? We know that 32-bit is too small, and the next best size is 64-bit words or with nanoseconds a 96-bit struct. The last non-power-of-two machine that I worked on was dumped >10 years ago and never had a C compiler. These are of academic interest. There is no practical intermediate size between a useful range and a 64-bit second counter. I think it is much more of an burden for the application programmer in the end to leave the time encoding and epoch undefined. > * We should specify better what happens before the epoch for TIME_UTC > and TIME_TAI. Actually, I would suggest that we specify the functionality of a xtime_make(&xtp, &tmptr, NULL); call completely by providing an example of a correct implementation in the standard (should be possible in less than 50 lines). Real code is much clearer here than any pseudo-mathematic specification. I started to add such example code to my web page a few days ago, but was interrupted and didn't get around yet to finish. Volunteers are welcome (especially getting the leap year formula for negative years correct might be a bit of a brain tweezer). Such example code resolves many ambiguities and also should solve your concern here. As far as TIME_TAI is concerned, I do not expect *ANY* implementation to support xtime_conv with pre-1972 TIME_TAI values. The other functions do not care about the difference between TIME_TAI and TIME_UTC anyway, and the semantics of the TIME_UTC clock relative to the Gregorian calendar withh be specified in the example code. > * We shouldn't insist on a particular type like `int_fast64_t' for > timestamps. I assume that this type was chosen to encourage > portability, I chose it for range and efficiency and fortunately. With int_fast64_t C provides me with exactly what I had in mind. I am not sure what type of portability you are referring to. > but it's not truly portable, since int_fast64_t might > have more than 64 bits. Please explain what the problem would be there. I don't see any. > Also, as mentioned above, it's way way > overkill for almost all applications. It's better to keep the > timestamp type a bit more abstract, like stime_t, and to place > constraints on it as needed, as described above. The abstractness of types like time_t in ISO C 89 was not done because this abstractness was considered to be good and beautiful design. On the contrary, is was a necessary hack because the ISO C standard had to be backwards compatible with a few strange C implementations. In this respect, ISO C 89 was a step backwards compared to K&R C. (Special thanks to Nick Maclaren <nmm1(a)cus.cam.ac.uk> for providing me with the historic background on this.) To my big surprise, many people today start to admire the hacky type mess that ISO C had to introduce because of bad PC compilers as glorious and wonderful abstractness, having completely forgotten the original reasons for all the awful type-uncertainties of ISO C 89. > * The stime_get interface is confusing, since it has several > operational functions. It's better to separate them out into one C > function for each operational function; e.g. we should have a > separate function stime_getres to get the resolution, instead of > passing a flag to stime_get to have it return the resolution instead > of the current time. Similarly, we should have a separate function > that gives us an error bound on the clock, rather than have a > TIME_SYNC flag. I considered defining several functions, and then deliberately packed all these functions into a single one. The main reason is that this packing of functionality allows implementors to add more functionality by just giving additional option and return bits a meaning, without cluttering up the namespace in non-portable ways. My proposed xtime_get interface allows you to add additional clocks to be requested (UT1 is one example I mentioned in a note in the proposal), or allows additional data to be requested (like is the clock coming in over a trusted channel, when was the last connection to this clock, estimated error interval size, etc.). I prefer to have a single more universal function that provides a clear way of addition additional functionality in a portable way over a set of functions that leave no room for extensions. It is always easy to add another biot, but is is difficult to add another function in implementations in a binary compatible way (thinking about shared libraries and these issues). > * We should require at least POSIX-style time zone specifications for > tz_prep, and should suggest Olson-style. As things stand, there's > little that portable code can do with that function. Requiring POSIX-style time zone specifications as a minimum functionality would be ok for me, but so would be to leave the string completely application defined and just mentioning POSIX as one possible implementation. I don't know whether the Olson-style ones are standardizable unless we get some sort of official ISO registry for time zone specifications. As I have pointed out before, I don't like the continent prefix in the Olson/style names, therefore I do not want to make this particular syntax immortal in an ISO standard (I much prefer just ":Paris" over "Europe/Paris"). Note that the tzstring will usually be directly entered by the user (say via a config file or via an environment variable), and the portable application does not have to be aware of the syntax used on this system. > * We should codify the convention that getenv("TZ") returns the > user-preferred time zone. A null tzstring should expand to a > system-defined time zone. This functionality is in practice and is > useful e.g. in mailer software, where you may or may not want to > allow the user to specify the time zone. OK, that sounds like a good idea. > * stime_make still has the old mktime problem that the function can't > distinguish a request for ``3 days after Feb 28'' from a request for > ``1 month before Mar 31''. It's silly that mktime thinks that 1 > month before Mar 31 is Mar 3 (or 2, if it's a leap year). We should > fix this. I think I fixed this very nicely by not requiring xtime_make to handle *any* invalid time representations. If you want 3 days after Feb 28, then you just add 3 * 86400 to the sec field. The extremely ugly hacks with mktime overflows and underflows have become obsolete by defining the encoding of the time representation to allow direct arithmetic. It is very difficult to define mktime overflow behavior nicely, so why bother if there is no need? > * The proposal for strfstime still involves magic; e.g. how can the > strftime easily determine the time zone abbreviation? strfxtime gets the timezone object passed as a paremeter. All information can be stored in there and accessed directly. No need to extend struct tm. > I'd rather > have a strftime that could in principle be written by the user; it's > common practice to write augmented strftime implementations, which > grind their teeth over questions like these, and it'd be better if > we let people write such functions cleanly. If you need access to the zone name, then simply use strfxtime to access it. I don't understand why it should be stored in any struct tm extention if we have a function to read it. > This will involve a new > type `struct stm' that contains extra members so that no more magic > is needed. Something like this: > > struct stm { > stime_t year; > int month; > int month_day; > int hour; > int minute; > int second; > stime_t utc_offset; > stime_t dst_offset; > const char *zone; > const char *zone_description; > }; No, please no additional structs. The existing one is good enough to represent and handle a full broken-down time. All other information is fully accessible via strfxtime. I consider the mixture of brocken-down time and timezone information conceptually dubious. For me a time zone is a function that maps broken-down times onto UTC, and not just auxiliary data on a broken-down time. The existing tm_isdst field seems to me to be sufficient (although not optimal) to handle ambiguities. > * We shouldn't have a separate error function just for stime. Instead, > functions that report errors should yield an error number, which can > be passed as an argument to strerror. This will simplify the interface > (e.g. we don't need to worry about LC_MESSAGES). That's perhaps worth thinking about. It depends on how detailed you want to make these error messages, and whether a single number can carry all information. Timezone strings can be rather tricky to get right and a comfortable diagnostic might be useful here. 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/>

5 13

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

FW: Changes in zoneinfo
by Olson, Arthur David (NCI) Sept. 28, 1998

Sept. 28, 1998

-----Original Message----- From: Marcos Tadeu [SMTP:marcos@MicroLink.com.br] Sent: Sunday, September 27, 1998 12:11 PM To: tz(a)elsie.nci.nih.gov Subject: Changes in zoneinfo There are a DS for 1998(in)/1999(out). The Brazilian official page is http://pcdsh01.on.br/verao1.html This diff is generate from tzdata1998c.tar.gz file in slackware package. -------------------------------------------------------------- --- southamerica.orig Sat Feb 28 15:32:26 1998 +++ southamerica Sun Sep 27 13:07:49 1998 @@ -289,10 +289,15 @@ # Brazil Prepares for Papal Visit # </a>, # Church Net UK (1997-10-02). +# +# From Marcos Tadeu (1998-10-27): +# In 1998, the DS begin in October 11 and end in Feb 21, 1999. +# Brazilian official page: http://pcdsh01.on.br./verao1.html +# Rule Brazil 1997 only - Oct 6 0:00 1:00 D 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 +Rule Brazil 1998 max - Oct Sun>=11 0:00 1:00 D +Rule Brazil 1999 max - Feb Sun>=17 0:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] # ----------------------------------------------------------

2 1

FW: zoneinfo changes for Europe/Latvia
by Olson, Arthur David (NCI) Sept. 28, 1998

Sept. 28, 1998

-----Original Message----- From: alexander smishlajev [SMTP:als@turnhere.com] Sent: Monday, September 28, 1998 12:21 PM To: tz(a)elsie.nci.nih.gov Subject: zoneinfo changes for Europe/Latvia timezone info for Latvia is out of date. since 1997, switching to the "winter" time occurs at the end of October. please apply the following patch. thank you. alexander smishlajev <<europe.dif>>

2 1