- tz - lists.iana.org

Summary of problems with draft C9x <time.h>, and a proposed fix
by Paul Eggert Sept. 15, 1998

Sept. 15, 1998

Rex Jaeschke, NCITS/J11 chair, recently sent me a copy of document J11/98-048, which contains the disposition by J11 of my public review comments regarding the C9x standard Committee Draft (CD) 1 (CD 9899, Ballot Document N2620). One of my comments was not satisfactorily resolved, and I'd like to follow up in the hope of improving the eventual standard. I'm referring to Comment 14 in US0011 (1998-03-04), my comment about problems in the struct-tmx-related changes by CD 1 to <time.h>. Unfortunately, many of these problems remain in CD 2, and I've since learned of other problems. I summarize these remaining problems in Appendix 1 below. Also, Clive Feather (who I understand is responsible for most of the <time.h> changes in CDs 1 and 2) has proposed that a new <time.h> section be written to address these problems. I welcome this proposal, and would like to contribute. However, I believe that it's too late in the standardization process to introduce major improvements to <time.h>, as there will be insufficient time to gain implementation experience with these changes, experience that is needed for proper review. Instead, I propose that <time.h>'s problems be fixed by removing the struct-tmx-related changes to <time.h>, reverting to the the current ISO C standard (C89); we can then come up with a better <time.h> for the next standard (C0x). In other words, I propose the following: * Change <time.h> to define only the types and functions that were defined in C89's <time.h>, and to remove a new requirement on mktime. Appendix 2 gives the details. * Work with Clive Feather and other interested parties to write and test a revised <time.h> suitable for inclusion in C0x. Please let me know of any way that I can further help implement this proposal. ------------------------------------------------------------ Appendix 1. Problems in the struct-tmx-related part of <time.h> Here is a summary of technical problems in the struct-tmx-related part of CD 2 (1998-08-03), section 7.23. The problems fall into two basic areas: * struct tmx is not headed in the right direction. The struct-tmx-related changes do not address several well-known problems with C89 <time.h>, and do not form a good basis for addressing these problems. These problems include the following. - Lack of precision. The standard does not require precise timekeeping; typically, time_t has only 1-second precision. - Inability to determine properties of time_t. There's no portable way to determine the precision or range of time_t. - Poor arithmetic support for the time_t type. difftime is not enough for many practical applications. - The new interface is not reentrant. A common extension to C89 is the support of reentrant versions of functions like localtime. This extension is part of POSIX.1. There's no good reason (other than historical practice) for time-related functions to rely on global state; any new extensions should be reentrant. - No control over time zones. There's no portable way for an application to inquire about the time in New York, for example, even if the implementation supports this. - Missing conversions. There's no way to convert between UTC and TAI, or between times in different time zones, or to determine which time zone is in use. - No reliable interval time scale. If the clock is adjusted to keep in sync with UTC, there's no reliable way for a program to ignore this change. - One cannot apply strftime to the output of gmtime, as the %Z and %z formats may be misinterpreted. (Credit: I've borrowed many of the above points from discussions by Clive Feather and Markus Kuhn.) * struct tmx has several technical problems of its own. Even on its own terms, struct tmx has several technical problems that would need to be fixed before being made part of a standard. These problems include the following. - In 7.23.1 paragraph 5, struct tmx's tm_zone member counts minutes. This disagrees with common practice, which is to extend struct tm by adding a new member tm_gmtoff that is UTC offset in seconds. The extra precision is needed to support old time stamps -- UTC offsets that were not a multiple of one minute used to be quite common, and in at least one locale this practice did not die out until 1972. - The tm_leapsecs member defined by 7.23.1 paragraph 5 is an integer, but it is supposed to represent TAI - UTC, and this value is not normally an integer for time stamps before 1972. Also, it's not clear what this value should be for time stamps before the introduction of TAI in the 1950s. - The tm_ext and tm_extlen members defined by 7.23.1 paragraph 5 use a new method to allow for future extensions. This method has never before been tried in the C Standard, and is likely to lead to problems in practice. For example, the draft makes no requirement on the storage lifetime of storage addressed by tm_ext. This means that an application cannot reliably dereference the pointer returned by zonetime, because it has no way of knowing when the tm_ext member points to freed storage. - 7.23.2.3 paragraph 4 adds the following requirement for mktime not present in C89: If the call is successful, a second call to the mktime function with the resulting struct tm value shall always leave it unchanged and return the same value as the first call. This requirement was inspired by the struct-tmx-related changes to <time.h>, but it requires changes to existing practice, and it cannot be implemented without hurting performance or breaking binary compatibility. For example, suppose I am in Sri Lanka, and invoke mktime on the equivalent of 1996-10-26 00:15:00 with tm_isdst==0. There are two distinct valid time_t values for this input, since Sri Lanka moved the clock back from 00:30 to 00:00 that day, permanently. There is no way to select the time_t by inspecting tm_isdst, since both times are standard time. On examples like these, C89 allows mktime to return different time_t values for the same input at different times during the execution of the program. This is common existing practice, but it is prohibited by this new requirement. It's possible to satisfy this new requirement by adding a new struct tm member, which specifies the UTC offset. However, this would break binary compatibility. It's also possible to satisfy this new requirement by always returning the earlier time_t value in ambiguous cases. However, this can greatly hurt performance, as it's not easy for some implementations to determine that the input is ambiguous; it would require scouting around each candidate returned value to see whether the value might be ambiguous, and this step would be expensive. - The limits on ranges for struct tmx members in 7.23.2.6 paragraph 2 are unreasonably tight. For example, they disallow the following program on a POSIX.1 host with a 32-bit `long', since `time (0)' currently returns values above 900000000 on POSIX.1 hosts, which is well above the limit LONG_MAX/8 == 268435455 imposed by 7.23.2.6. #include <time.h> struct tmx tm; int main() { char buf[1000]; time_t t = 0; /* Add current time to POSIX.1 epoch, using mkxtime. */ tm.tm_version = 1; tm.tm_year = 1970 - 1900; tm.tm_mday = 1; tm.tm_sec = time (0); if (mkxtime (&tm) == (time_t) -1) return 1; strfxtime (buf, sizeof buf, "%Y-%m-%d %H:%M:%S", &tm); puts (buf); return 0; } The limits in 7.23.2.6 are not needed. A mktime implementation need not check for overflow on every internal arithmetic operation; instead, it can cheaply check for overflow by doing a relatively simple test at the end of its calculation. - 7.23.2.6 paragraph 3 contains several technical problems: . In some cases, it requires mkxtime to behave as if each day contains 86400 seconds, even if the implementation supports leap seconds. For example, if the host supports leap seconds and uses Japan time, then using mkxtime to add 1 day to 1999-01-01 00:00:00 must yield 1999-01-01 23:59:59, because there's a leap second at 08:59:60 that day in Japan. This is not what most programmers will want or expect. . The explanation starts off with ``Values S and D shall be determined as follows'', but the code that follows does not _determine_ S and D; it consults an oracle to find X1 and X2, which means that the code merely places _constraints_ on S and D. A non-oracular implementation cannot in general determine X1 and X2 until it knows S and D, so the code, if interpreted as a definition, is a circular one. . The code suffers from arithmetic overflow problems. For example, suppose tm_hour == INT_MAX && INT_MAX == 32767. Then tm_hour*3600 overflows, even though tm_hour satisfies the limits of paragraph 2. . The code does not declare the types of SS, M, Y, Z, D, or S, thus leading to confusion. Clearly these values cannot be of type `int', due to potential overflow problems like the one discussed above. It's not clear what type would suffice. . The definition for QUOT yields numerically incorrect results if either (b)-(a) or (b)-(a)-1 overflows. Similarly, REM yields incorrect results if (b)*QUOT(a,b) overflows. . The expression Y*365 + (Z/400)*97 + (Z%400)/4 doesn't match the Gregorian calendar, which has special rules for years that are multiples of 100. . The code is uncommented, so it's hard to understand and evaluate. For example, the epoch (D=0, S=0) is not described; it appears to be (-0001)-12-31 Gregorian, but this should be cleared up. - 7.23.3.7 says that the number of leap seconds is the ``UTC-UT1 offset''. It should say ``UTC - TAI''. ------------------------------------------------------------ Appendix 2. Details of proposed change to <time.h> Here are the details about my proposed change to <time.h>. This change reverts the <time.h> part of the standard to define only the types, functions, and macros that were defined in C89's <time.h>. It also removes the hard-to-implement requirement in 7.23.2.3 paragraph 4. * 7.23.1 paragraph 2. Remove the macros _NO_LEAP_SECONDS and _LOCALTIME. * 7.23.1 paragraph 3. Remove the type `struct tmx'. * 7.23.1 paragraph 5 (struct tmx). Remove this paragraph. * 7.23.2.3 paragraph 3 (mktime normalization). Remove this paragraph. * 7.23.2.3 paragraph 4. Remove the phrase ``and return the same value''. It's not feasible to return the same value in some cases; see the discussion of 7.23.2.3 paragraph 4 above. * 7.23.2.4 (mkxtime). Remove this section. * 7.23.2.6 (normalization of broken-down times). Remove this section; this means footnote 252 will be removed. * 7.23.3 paragraph 1. Remove the reference to strfxtime. * 7.23.3.6 (strfxtime). Remove this section. * 7.23.3.7 (zonetime). Remove this section.

1 0

Combination Session IERS Workshop
by iers＠hpvlbi.obspm.fr Sept. 9, 1998

Sept. 9, 1998

Subject : IERS Workshop in Potsdam : Last call for paper proposals for topic 2 (Combinations) Dear Colleagues Please find thereafter the tentative Combination Session agenda to be held on Wednesday 30 September: Topic 2: Combinations of Data for IERS Products; list of papers as of 9 September "Combination of Earth Orientation Series from Various Techniques" D. Gambis and E. Eisop "A Kalman-Filter-Based Approach to Combining Earth Orientation Series" Richard Gross "Contribution to the problem of combination of the data obtained by different techniques" Jan Vondrak "A combined series from length of day measurements: performance and analysis" L. I. Fernandez, E. F. Arias , D. Gambis "DORIS Orbit Determination Service (SOD)" J.P. Berthias, A. Guitart, S. Houry, A. Piuzzi "On unification and combination of SLR EOP series" Zinovy Malkin "New IGS Realization of ITRF and Simultaneous Combination of Station and EOP solutions" R. Ferland, J. Kouba, Y Mireault "Combination of VLBI, GPS and SLR data at the observation level" P.H. Andersen "Reference frame combination (of multi-techniques) at the level of processing" Sheng Zhu and Christoph Reigber "Russian VLBI for astronomy and geodesy: current status and prospects" Andrey Finkelstein Thank you for your eventual comments and suggestions concerning this agenda. Additional presentation proposals are still welcome. Abstracts should be send to : Daniel Gambis (gambis(a)obspm.fr) and Joachim Hoepfner (ho(a)gfz-potsdam.de) Thank you Best regards Daniel Gambis

1 0

Revision of ISO C 9x <time.h>
by Markus Kuhn Sept. 6, 1998

Sept. 6, 1998

The new ISO C draft is on <ftp://dkuug.dk/JTC1/SC22/wg14/index.html>. I think, the following message might be of great interest to many here. I hope Clive has in the meantime managed to join the tz list, such that we can discuss proposals here. Markus ------- Forwarded Message From: "Clive D.W. Feather" <clive(a)demon.net> Subject: It's about time [sorry for the bad joke] I'm sorry I've taken so long to get back to people about this. This email is going to all the people who have expressed to me an interest in the C9X time functions. C9X CD2 (aka the FCD) is now published (it can be found on the DKUUG web site). It basically contains the same material in <time.h> as CD1 did, though a few minor errors have been corrected and Keld's %O and %E modifiers have appeared. Everyone who's written to me has expressed dissatisfaction with some part or other of the current situation. Therefore I have a rather radical proposal to make: I suggest we write a complete new <time.h> section that addresses all our issues, and arrange for at least two, and preferably three or more, National Bodies to submit it as part of their response to CD2. I'm willing to act as the core editor for this work, provided: - people will write full pieces of text for me to drop in as needed; - people won't object to my use of editorial powers to tidy up and keep the wording consistent. I can provide web space where I will keep the working drafts. I suggest we start with what's in CD2 as a common base, though being ready to drop pieces if that's what we agree. In the meantime, here's all the issues that I'm aware of that our text would need to handle: (1) Clear definition of canonicalisation of times. (2) Unambigous mechanisms for converting between UTC and TAI, and between time zones, and for determining which is in use. (3) Clearer definitions of things like strftime conversions (all of these are in CD2, so this is a no-op). (4) Ability to determine the precision of times (a ticks per second macro, perhaps). This should be guaranteed to be <= 1 second over some range. (5) Ability to determine the range of time_t, with guaranteed minimum limits. (6) A member in struct tmx for access to subsecond resolution, and possibly new formats to access it. (7) The meaning of struct tm to remain source and binary compatible with C89. (8) Clearer definition of what struct tm[x] values must be handled by implementations. (9) All new functions to be re-entrant. (10) Rethink future expandibility of struct tmx. (11) Portable form for transferring time values between programs and implementations. Anything else ? I've no objection to this message having wider circulation, but only to people who aren't going to require more education than there's time for. -- Clive D.W. Feather | Regulation Officer, LINX | Work: <clive(a)linx.org> Tel: +44 1733 705000 | (on secondment from | Home: <cdwf(a)i.am> Fax: +44 1733 353929 | Demon Internet) | <http://i.am/davros> ------- End of Forwarded Message

5 10

latest time zone info
by David A. Coyle Sept. 2, 1998

Sept. 2, 1998

Hi: I'm subcontracting ona project at the USPS, and we need some reliable TimeZone info for the US. I have an FTP URL to your site, but it seems to be stale: is there a newer or otherwise more official source of time zone info? thanks, Dave Coyle Software Architect Tensor Information Systems Raleigh, NC

1 0

dls in Israel
by Rives McDow Sept. 2, 1998

Sept. 2, 1998

Dear Mr. Olsen, Here is an update on dls in Israel this year, both in an attached file and the text here. Sincerely, Rives McDow Wednesday, September 2, 1998 MK protests early end of daylight time MK Avraham Poraz (Meretz), who initiated the use of daylight time in Israel, has sharply criticized the Interior Ministry decision to end daylight time this Saturday at midnight. Poraz claimed that this year daylight time, which was supposed to end Oct. 17, has been shortened by 40 days. According to Poraz, its early end is a "blow to the majority of Israelis who want daylight time until the end of the summer." The Sept. 5 cutoff is intended to "serve the interests of a small minority of ultra-Orthodox Sephardic Jews who, during the [Hebrew] month of Elul, recite Slihot penitential prayers in the early morning hours and thus find daylight time inconvenient." This is another example of how Interior Minister Eli Suissa "favors the interests of a small minority at the expense of the interests of the majority," Poraz said. Suissa responded that although the law calls for a minimum 150 days of daylight time, this year it has been in force for 170. Regarding Poraz¹s claims about serving the interests of a minority, Suissa said that a committee that probed the entire issue and which generally confirmed the terms of the above law used professional criteria and did not take into consideration the "discomfort" of those who recite the Slihot prayers at this time of year. By Dalia Shehori, Ha¹aretz correspondent

1 0

RE: Possible Bug in INT_STRLEN_MAXIMUM macro
by Olson, Arthur David (NCI) Aug. 24, 1998

Aug. 24, 1998

-----Original Message----- From: Randy Thelen [SMTP:rthelen@netapp.com] Sent: Friday, August 21, 1998 7:17 PM To: tz(a)elsie.nci.nih.gov Cc: guy(a)netapp.com Subject: Possible Bug in INT_STRLEN_MAXIMUM macro The INT_STRLEN_MAXIMUM macro in lib/private.h used by, among other files, asctime.c, states in its comment field: /* ** 302 / 1000 is log10(2.0) rounded up. ... */ And then in the macro definition we find: #define INT_STRLEN_MAXIMUM(type) \ ... * 302 / 100 ... Me thinks this is not what was intended. Possibly it's an error, possibly it's the right thing. Could you send mail back telling me if this was on purpose? -- Randy Thelen Software Engineer Network Appliance, Inc. The bad news is that the macro definition indeed fails to match the comment; the good news is that the error results in over-generous sizing of arrays designed to hold ASCII representations of numbers. I've changed the "100" in the "#define" to the correct "1000"; the change will show up in the next version of tzcode. --ado

1 0

Revision of ISO C 9x <time.h>
by Markus Kuhn Aug. 22, 1998

Aug. 22, 1998

The new ISO C draft is on <ftp://dkuug.dk/JTC1/SC22/wg14/index.html>. I think, the following message might be of interest to many here: ------- Forwarded Message Date: Sat, 22 Aug 1998 21:00:08 +0100 To: David R Tribble <david.tribble(a)central.beasys.com>, Antoine.Leca(a)renault.fr, kuhn(a)cs.purdue.edu From: "Clive D.W. Feather" <clive(a)on-the-train.demon.co.uk> Reply-To: "Clive D.W. Feather" <clive(a)demon.net> Subject: It's about time [sorry for the bad joke] I'm sorry I've taken so long to get back to people about this. This email is going to all the people who have expressed to me an interest in the C9X time functions. C9X CD2 (aka the FCD) is now published (it can be found on the DKUUG web site). It basically contains the same material in <time.h> as CD1 did, though a few minor errors have been corrected and Keld's %O and %E modifiers have appeared. Everyone who's written to me has expressed dissatisfaction with some part or other of the current situation. Therefore I have a rather radical proposal to make: I suggest we write a complete new <time.h> section that addresses all our issues, and arrange for at least two, and preferably three or more, National Bodies to submit it as part of their response to CD2. I'm willing to act as the core editor for this work, provided: - - people will write full pieces of text for me to drop in as needed; - - people won't object to my use of editorial powers to tidy up and keep the wording consistent. I can provide web space where I will keep the working drafts. I suggest we start with what's in CD2 as a common base, though being ready to drop pieces if that's what we agree. In the meantime, here's all the issues that I'm aware of that our text would need to handle: (1) Clear definition of canonicalisation of times. (2) Unambigous mechanisms for converting between UTC and TAI, and between time zones, and for determining which is in use. (3) Clearer definitions of things like strftime conversions (all of these are in CD2, so this is a no-op). (4) Ability to determine the precision of times (a ticks per second macro, perhaps). This should be guaranteed to be <= 1 second over some range. (5) Ability to determine the range of time_t, with guaranteed minimum limits. (6) A member in struct tmx for access to subsecond resolution, and possibly new formats to access it. (7) The meaning of struct tm to remain source and binary compatible with C89. (8) Clearer definition of what struct tm[x] values must be handled by implementations. (9) All new functions to be re-entrant. (10) Rethink future expandibility of struct tmx. (11) Portable form for transferring time values between programs and implementations. Anything else ? I've no objection to this message having wider circulation, but only to people who aren't going to require more education than there's time for. - -- Clive D.W. Feather | Regulation Officer, LINX | Work: <clive(a)linx.org> Tel: +44 1733 705000 | (on secondment from | Home: <cdwf(a)i.am> Fax: +44 1733 353929 | Demon Internet) | <http://i.am/davros> Written on my laptop; please observe the Reply-To address ------- End of Forwarded Message

1 0

Possible Bug in INT_STRLEN_MAXIMUM macro
by Randy Thelen Aug. 21, 1998

Aug. 21, 1998

The INT_STRLEN_MAXIMUM macro in lib/private.h used by, among other files, asctime.c, states in its comment field: /* ** 302 / 1000 is log10(2.0) rounded up. ... */ And then in the macro definition we find: #define INT_STRLEN_MAXIMUM(type) \ ... * 302 / 100 ... Me thinks this is not what was intended. Possibly it's an error, possibly it's the right thing. Could you send mail back telling me if this was on purpose? -- Randy Thelen Software Engineer Network Appliance, Inc.

1 0

Lat. / Long to timezone conversion
by O'Kelly, David Aug. 12, 1998

Aug. 12, 1998

To whom it may concern, I am currently trying to identify if there are any existing software products which can carry out a Latitude / Longitude conversion to the corresponding timezone. Initially I am concentrating on data for the U.S., Canada & Mexico and was wondering if any relevant or pertinent information may be available on this subject. Thank you for any help you can provide. - regards Dave David O'Kelly Principal Software Engineer Communications Division Logica Inc. tel + 1 415 288 5200 fax + 1 415 288 5299 email okellyd(a)logica.com

1 0

tzdata1998g.tar.gz
by Olson, Arthur David (NCI) Aug. 11, 1998

Aug. 11, 1998

The file ftp://elsie.nci.nih.gov/pub/tzdata1998g.tar.gz is now available; it incorporates the Lithuanian change provided by mgedmin(a)pub.osf.it; it also moves creation of the GMT link with Etc/GMT to "etcetera" (from "backward") to ensure that the GMT file is created even where folks don't want the "backward" links (as suggested by Paul Eggert). --ado

2 1

Time zone suggestions for draft-ietf-calsch-ical-08.txt
by Paul Eggert Aug. 10, 1998

Aug. 10, 1998

Here are some suggested improvements, in the area of time zones, to the latest iCalendar draft (which I got from: ftp://ftp.isi.edu/internet-drafts/draft-ietf-calsch-ical-08.txt ). * A more consistent naming strategy for TZIDs. The current draft is inconsistent: for the same time zone it sometimes says "America-New_York", sometimes "America-New York", and sometimes other things like "Eastern". TZIDs are arbitrary, but a good naming convention can help reduce the number of errors, ease maintenance, and improve interoperability. iCalendar should recommend, but not require, the names in the public-domain Olson database (omitting the names present there only for backwards compatibility); this is the best widely-available prior art. For NYC this name would be "America/New_York". * A reference to the Olson database prior art. Many potential implementers don't know about this useful source, and have thereby propagated incorrect time zone data. * Allow UTC offsets that are not multiples of one minute. This is needed for historically recent applications (e.g. the time zone in Liberia up to 1972). * The examples should be a tad more careful about distinguishing between US Eastern time and New York time, since there was a lot of confusion about the Eastern time zone before, say, 1976. Here's a proposed line-by-line patch to the -08 draft, which embodies these suggestions. --- draft-ietf-calsch-ical-08.txt Wed Jul 15 10:41:12 1998 +++ draft-ietf-calsch-ical-08.txt-fix Thu Jul 16 17:27:13 1998 @@ -1730,7 +1730,7 @@ The following are examples of this property parameter: - DTSTART;TZID=America-New_York:19980119T020000 + DTSTART;TZID=America/New_York:19980119T020000 @@ -1740,7 +1740,7 @@ Internet Draft C&S Core Object Specification June 29, 1998 - DTEND;TZID=America-New_York:19980119T030000 + DTEND;TZID=America/New_York:19980119T030000 The TZID property parameter MUST NOT be applied to DATE-TIME or TIME properties whose time values are specified in UTC. @@ -2031,7 +2031,7 @@ section on Time Zone. For example, the following represents 2 AM in New York on Janurary 19, 1998: - DTSTART;TZID=America-New_York:19980119T020000 + DTSTART;TZID=America/New_York:19980119T020000 Example: The following represents July 14, 1997, at 1:30 PM in New York City in each of the three time formats, using the "DTSTART" @@ -2039,7 +2039,7 @@ DTSTART:19970714T133000 ;Local time DTSTART:19970714T173000Z ;UTC time - DTSTART;TZID=America-NYC:19970714T133000 ;Local time and time + DTSTART;TZID=America/New_York:19970714T133000 ;Local time and time ; zone reference @@ -2462,7 +2462,7 @@ Here is an example of evaluating multiple BYxxx rule parts. - DTSTART;TZID=US-Eastern:19970105T083000 + DTSTART;TZID=America/New_York:19970105T083000 RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; BYMINUTE=30 @@ -2683,7 +2683,7 @@ X-TIMEOFDAY:133000Z - X-TIMEOFDAY;TZID=America-New York:083000 + X-TIMEOFDAY;TZID=America/New_York:083000 4.3.13 URI @@ -2737,11 +2737,12 @@ utc-offset = time-numzone ;As defined above in time data type - time-numzone = ("+" / "-") time-hour time-minute + time-numzone = ("+" / "-") time-hour time-minute [time-second] Description: The PLUS SIGN character MUST be specified for positive - UTC offsets (i.e., ahead of UTC). The value of "-0000" is not - allowed. + UTC offsets (i.e., ahead of UTC). The values "-0000" and "-000000" + are not allowed. The time-second, if present, may not be 60; if + absent, it defaults to zero. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. @@ -2801,8 +2802,8 @@ Property names, parameter names and enumerated parameter values are case insensitive. For example, the property name "DUE" is the same as - "due" and "Due", DTSTART;TZID=Eastern:19980714T120000 is the same as - DtStart;TzID=Eastern:19980714T120000. + "due" and "Due", DTSTART;TZID=America/New_York:19980714T120000 is the same as + DtStart;TzID=America/New_York:19980714T120000. 4.6 Calendar Components @@ -3270,8 +3271,8 @@ locations adjust their time by a fraction of an hour. Standard Time is also known as Winter Time. Daylight Saving Time is also known as Advanced Time, Summer Time, or Legal Time in certain countries. The - following table shows the changes in time zone rules for the eastern - United States starting from 1967. Each line represents a description + following table shows the changes in time zone rules for New York City + starting from 1967. Each line represents a description or rule for a particular observance. Effective Observance Rule @@ -3368,11 +3369,22 @@ the time in question, and using the offset value from that observance. + [TZ] is an informal, public-domain collection of time zone + information, which is currently being maintained by volunteer + Internet participants, and is used in several operating systems. + This database contains current and historical time zone information + for a wide variety of locations around the globe; it provides a + time zone identifier for every unique time zone rule set in actual + use since 1970, with historical data going back to the introduction + of standard time. + The top-level properties in a "VTIMEZONE" calendar component are: The mandatory "TZID" property is a text value that uniquely identifies the VTIMZONE calendar component within the scope of an - iCalendar object. + iCalendar object. The name SHOULD should be the name of a time + zone in [TZ], and the other "VTIMEZONE" properties SHOULD define a + subset of the rules given in [TZ]. The optional "LAST-MODIFIED" property is a UTC value that specifies the date and time that this time zone definition was last updated. @@ -3392,7 +3404,7 @@ "TZOFFSETFROM" is combined with "DTSTART" to define the effective onset for the time zone sub-component definition. For example, the following represents the time at which the observance of Standard - Time took effect in Fall 1967 for the eastern United States: + Time took effect in Fall 1967 for New York City: DTSTART:19671029T020000 @@ -3445,8 +3457,8 @@ Example: The following are examples of the "VTIMEZONE" calendar component: - This is an example showing time zone information for the Eastern - United States using "RDATE" property. Note that this is only suitable + This is an example showing time zone information for New York City + using the "RDATE" property. Note that this is only suitable for a recurring event that starts on or later than April 6, 1997 at 03:00:00 EDT (i.e., the earliest effective transition date and time) and ends no later than April 7, 1998 02:00:00 EST (i.e., latest valid @@ -3455,7 +3467,7 @@ starting June 1, 1997, ending December 31, 1997. BEGIN:VTIMEZONE - TZID:America-New_York + TZID:America/New_York LAST-MODIFIED:19870101T000000Z BEGIN:STANDARD DTSTART:19971026T020000 @@ -3481,16 +3493,16 @@ END:DAYLIGHT END:VTIMEZONE - This is a simple example showing the current time zone rules for the - Eastern United States using a RRULE recurrence pattern. Note that + This is a simple example showing the current time zone rules for + New York City using a RRULE recurrence pattern. Note that there is no effective end date to either of the Standard Time or Daylight Time rules. This information would be valid for a recurring event starting today and continuing indefinitely. BEGIN:VTIMEZONE - TZID:America-New_York + TZID:America/New_York LAST-MODIFIED:19870101T000000Z - TZURL:http://zones.stds_r_us.net/tz/America-New_York + TZURL:http://zones.stds_r_us.net/tz/America/New_York BEGIN:STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 @@ -3507,12 +3519,12 @@ END:DAYLIGHT END:VTIMEZONE - This is an example showing a fictitious set of rules for the Eastern - United States, where the Daylight Time rule has an effective end date + This is an example showing a fictitious set of rules for New York City + where the Daylight Time rule has an effective end date (i.e., after that date, Daylight Time is no longer observed). BEGIN:VTIMEZONE - TZID:America-New_York + TZID:America/New_York LAST-MODIFIED:19870101T000000Z BEGIN:STANDARD DTSTART:19671029T020000 @@ -3538,13 +3550,13 @@ Internet Draft C&S Core Object Specification June 29, 1998 - This is an example showing a fictitious set of rules for the Eastern - United States, where the first Daylight Time rule has an effective + This is an example showing a fictitious set of rules for New York City, + where the first Daylight Time rule has an effective end date. There is a second Daylight Time rule that picks up where the other left off. BEGIN:VTIMEZONE - TZID:America-New_York + TZID:America/New_York LAST-MODIFIED:19870101T000000Z BEGIN:STANDARD DTSTART:19671029T020000 @@ -4974,14 +4986,14 @@ Example: The following are examples of non-globally unique time zone identifiers: - TZID:America-New_York + TZID:America/New_York - TZID:California-Los_Angeles + TZID:America/Los_Angeles The following is an example of a globally unique time zone identifier: - TZID:/US-New_York-New_York + TZID:/America/New_York 4.8.3.2 Time Zone Name @@ -5139,7 +5151,7 @@ Example: The following is an example of this property: - TZURL:http://timezones.r.us.net/tz/US-California-Los_Angeles + TZURL:http://timezones.r.us.net/tz/America/Los_Angeles @@ -5867,7 +5879,7 @@ RDATE:19970714T123000Z - RDATE;TZID=US-EASTERN:19970714T083000 + RDATE;TZID=America/New_York:19970714T083000 RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, 19960404T010000Z/PT3H @@ -5938,11 +5950,11 @@ rrulparam = *(";" xparam) - Example: All examples assume the Eastern United States time zone. + Example: All examples assume New York City time. Daily for 10 occurrences: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=DAILY;COUNT=10 ==> (1997 9:00 AM EDT)September 2-11 @@ -5956,7 +5968,7 @@ Internet Draft C&S Core Object Specification June 29, 1998 - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z ==> (1997 9:00 AM EDT)September 2-30;October 1-25 @@ -5964,7 +5976,7 @@ Every other day - forever: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=DAILY;INTERVAL=2 ==> (1997 9:00 AM EDT)September2,4,6,8...24,26,28,30; October 2,4,6...20,22,24 @@ -5973,14 +5985,14 @@ Every 10 days, 5 occurrences: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID/America/New_York:19970902T090000 RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12 Everyday in January, for 3 years: - DTSTART;TZID=America-New York:19980101T090000 + DTSTART;TZID=America/New_York:19980101T090000 RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA or @@ -5992,7 +6004,7 @@ Weekly for 10 occurrences - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=WEEKLY;COUNT=10 ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 @@ -6000,7 +6012,7 @@ Weekly until December 24, 1997 - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 @@ -6009,7 +6021,7 @@ Every other week - forever: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 Dawson/Stenerson 97 Expires January 1999 @@ -6028,7 +6040,7 @@ Weekly on Tuesday and Thursday for 5 weeks: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH or RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH @@ -6038,7 +6050,7 @@ Every other week on Monday, Wednesday and Friday until December 24, 1997, but starting on Tuesday, September 2, 1997: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; BYDAY=MO,WE,FR ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October @@ -6048,14 +6060,14 @@ Every other week on Tuesday and Thursday, for 8 occurrences: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH ==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16 Monthly on the 1st Friday for ten occurrences: - DTSTART;TZID=America-New York:19970905T090000 + DTSTART;TZID=America/New_York:19970905T090000 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR ==> (1997 9:00 AM EDT)September 5;October 3 @@ -6065,7 +6077,7 @@ Monthly on the 1st Friday until December 24, 1997: - DTSTART;TZID=America-New York:19970905T090000 + DTSTART;TZID=America/New_York:19970905T090000 RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR ==> (1997 9:00 AM EDT)September 5;October 3 @@ -6083,7 +6095,7 @@ Every other month on the 1st and last Sunday of the month for 10 occurrences: - DTSTART;TZID=America-New York:19970907T090000 + DTSTART;TZID=America/New_York:19970907T090000 RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU ==> (1997 9:00 AM EDT)September 7,28 @@ -6093,7 +6105,7 @@ Monthly on the second to last Monday of the month for 6 months: - DTSTART;TZID=America-New York:19970922T090000 + DTSTART;TZID=America/New_York:19970922T090000 RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO ==> (1997 9:00 AM EDT)September 22;October 20 @@ -6102,7 +6114,7 @@ Monthly on the third to the last day of the month, forever: - DTSTART;TZID=America-New York:19970928T090000 + DTSTART;TZID=America/New_York:19970928T090000 RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 ==> (1997 9:00 AM EDT)September 28 @@ -6112,7 +6124,7 @@ Monthly on the 2nd and 15th of the month for 10 occurrences: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 ==> (1997 9:00 AM EDT)September 2,15;October 2,15 @@ -6121,7 +6133,7 @@ Monthly on the first and last day of the month for 10 occurrences: - DTSTART;TZID=America-New York:19970930T090000 + DTSTART;TZID=America/New_York:19970930T090000 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 ==> (1997 9:00 AM EDT)September 30;October 1 @@ -6131,7 +6143,7 @@ Every 18 months on the 10th thru 15th of the month for 10 occurrences: - DTSTART;TZID=America-New York:19970910T090000 + DTSTART;TZID=America/New_York:19970910T090000 RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14, 15 @@ -6148,7 +6160,7 @@ Every Tuesday, every other month: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU ==> (1997 9:00 AM EDT)September 2,9,16,23,30 @@ -6158,7 +6170,7 @@ Yearly in June and July for 10 occurrences: - DTSTART;TZID=America-New York:19970610T090000 + DTSTART;TZID=America/New_York:19970610T090000 RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 ==> (1997 9:00 AM EDT)June 10;July 10 @@ -6171,7 +6183,7 @@ Every other year on January, February, and March for 10 occurrences: - DTSTART;TZID=America-New York:19970310T090000 + DTSTART;TZID=America/New_York:19970310T090000 RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 ==> (1997 9:00 AM EST)March 10 @@ -6181,7 +6193,7 @@ Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: - DTSTART;TZID=America-New York:19970101T090000 + DTSTART;TZID=America/New_York:19970101T090000 RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 ==> (1997 9:00 AM EST)January 1 @@ -6194,7 +6206,7 @@ Every 20th Monday of the year, forever: - DTSTART;TZID=America-New York:19970519T090000 + DTSTART;TZID=America/New_York:19970519T090000 RRULE:FREQ=YEARLY;BYDAY=20MO @@ -6213,7 +6225,7 @@ Monday of week number 20 (where the default start of the week is Monday), forever: - DTSTART;TZID=America-New York:19970512T090000 + DTSTART;TZID=America/New_York:19970512T090000 RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO ==> (1997 9:00 AM EDT)May 12 @@ -6223,7 +6235,7 @@ Every Thursday in March, forever: - DTSTART;TZID=America-New York:19970313T090000 + DTSTART;TZID=America/New_York:19970313T090000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH ==> (1997 9:00 AM EST)March 13,20,27 @@ -6233,7 +6245,7 @@ Every Thursday, but only during June, July, and August, forever: - DTSTART;TZID=America-New York:19970605T090000 + DTSTART;TZID=America/New_York:19970605T090000 RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 ==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31; @@ -6246,8 +6258,8 @@ Every Friday the 13th, forever: - DTSTART;TZID=America-New York:19970902T090000 - EXDATE;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 + EXDATE;TZID=America/New_York:19970902T090000 RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 ==> (1998 9:00 AM EST)February 13;March 13;November 13 @@ -6266,7 +6278,7 @@ Internet Draft C&S Core Object Specification June 29, 1998 - DTSTART;TZID=America-New York:19970913T090000 + DTSTART;TZID=America/New_York:19970913T090000 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 ==> (1997 9:00 AM EDT)September 13;October 11 @@ -6278,7 +6290,7 @@ Every four years, the first Tuesday after a Monday in November, forever (U.S. Presidential Election day): - DTSTART;TZID=America-New York:19961105T090000 + DTSTART;TZID=America/New_York:19961105T090000 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4, 5,6,7,8 @@ -6290,7 +6302,7 @@ The 3rd instance into the month of one of Tuesday, Wednesday or Thursday, for the next 3 months: - DTSTART;TZID=America-New York:19970904T090000 + DTSTART;TZID=America/New_York:19970904T090000 RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 ==> (1997 9:00 AM EDT)September 4;October 7 @@ -6298,7 +6310,7 @@ The 2nd to last weekday of the month: - DTSTART;TZID=America-New York:19970929T090000 + DTSTART;TZID=America/New_York:19970929T090000 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 ==> (1997 9:00 AM EDT)September 29 @@ -6308,14 +6320,14 @@ Every 3 hours from 9:00 AM to 5:00 PM on a specific day: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z ==> (September 2, 1997 EDT)09:00,12:00,15:00 Every 15 minutes for 6 occurrences: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15 @@ -6330,14 +6342,14 @@ Every hour and a half for 4 occurrences: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30 Every 20 minutes from 9:00 AM to 4:40 PM every day: - DTSTART;TZID=America-New York:19970902T090000 + DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 or RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 @@ -6351,14 +6363,14 @@ An example where the days generated makes a difference because of WKST: - DTSTART;TZID=America-New York:19970805T090000 + DTSTART;TZID=America/New_York:19970805T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO ==> (1997 EDT)Aug 5,10,19,24 changing only WKST from MO to SU, yields different results... - DTSTART;TZID=America-New York:19970805T090000 + DTSTART;TZID=America/New_York:19970805T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU ==> (1997 EDT)August 5,17,19,31 @@ -6963,14 +6975,14 @@ The following example specifies a group scheduled meeting that begin at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, 1998. The "Organizer" has scheduled the meeting with one or more - calendar users in a group. A time zone specification for Eastern - United States has been specified. + calendar users in a group. A time zone specification for New York + City has been specified. BEGIN:VCALENDAR PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VTIMEZONE - TZID:Eastern US + TZID:America/New_York BEGIN:STANDARD DTSTART:19981025T020000 RDATE:19981025T020000 @@ -6997,8 +7009,8 @@ CLASS:PUBLIC CREATED:19980309T130000Z SUMMARY:XYZ Project Review - DTSTART;TZID=US-Eastern:19980312T083000 - DTEND;TZID=US-Eastern:19980312T093000 + DTSTART;TZID=America/New_York:19980312T083000 + DTEND;TZID=America/New_York:19980312T093000 LOCATION:1CP Conference Room 4350 END:VEVENT END:VCALENDAR @@ -7424,6 +7436,9 @@ [RFC 2279] "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. + + [TZ] Olson, A.D., et al, Time zone code and data, + ftp://elsie.nci.nih.gov/pub/, updated periodically. [VCARD] Internet Mail Consortium, "vCard - The Electronic Business Card Version 2.1", http://www.imc.org/pdi/vcard-21.txt, September

5 11

Time zone update
by Marius Gedminas Aug. 7, 1998

Aug. 7, 1998

I would like to inform that in this year Lithuanian time zone (Europe/Vilnius) was changed. Here's a diff: Yours, -- Marius Gedminas "A Hacker is any person who derives E-mail: mgedmin(a)pub.osf.lt joy from discovering ways to WWW: http://www-public.osf.lt/~mgedmin/ circumvent limitations." rab'86

1 0

Re: time_t (2000 problem)
by Antoine Leca Aug. 6, 1998

Aug. 6, 1998

Hi, Stephen Baynes wrote: > > > That is a thing I am interested in investigating. > > Are you interested to work in this area (I search after volunteers!) > > > > I would be interested if I had the time. OK. I forgot to point you to the elsie mailing list. In any case, if work is effectively begining, it will take place closely to this group. Do you know it? If not, you might consider subscribing (mail at tz-request(a)elsie.nci.nih.gov, IIRC). Antoine

2 2

Re: time_t (2000 problem)
by Stephen Baynes Aug. 5, 1998

Aug. 5, 1998

Antoine.Leca wrote: > > I forgot to point you to the elsie mailing list. > In any case, if work is effectively begining, it will take place > closely to this group. > Do you know it? > I have not heard of it. What is it about? I assume something about time, but is it very specific or very general? Also how much trafic does it carry? > If not, you might consider subscribing (mail at > tz-request(a)elsie.nci.nih.gov, IIRC). > If it is of interest and does not carry too much trafic, then I will subscribe. Stephen

1 0

Graphic and Cartoon Competition
by MPaul5045＠aol.com Aug. 3, 1998

Aug. 3, 1998

Graphic and Cartoon Competition Concours de l'art graphique et de la caricature Grafik- und Karikaturenwettbewerb <A HREF="http://www.zibb.de">http://www.zibb.de</A> Grafik- und Karikaturenwettbewerb der Zahntechniker-Innung Berlin-Brandenburg zum Thema "Für Zähne gibt es keine Alternative. Aber Ersatz!" Unter dem Motto "Wer gesunde und schöne Zähne hat, fühlt sich wohl und lacht gern" veranstalteten wir 1996/97 einen großen Foto- und Ideenwettbewerb. Weit über 1000 Teilnehmer reichten hierzu ihre Beiträge ein. Die Besten wurden prämiert und sind im Internet (<A HREF="http://www.zibb.de">http://www.zibb.de </A>) unter der Rubrik "Foto- und Ideenwettbewerb" dokumentiert. Mit unserem neuen Grafik- und Karikaturenwettbewerb wollen wir an diese erfolgreiche Aktion anknüpfen. Machen Sie mit! Teilnahmebedingungen · Gesucht werden zum Wettbewerbsthema selbst gestaltete Grafiken und Karikaturen. · Wettbewerbsbeiträge können eingereicht werden in der Zeit vom 1. April bis 30. November 1998. Sie sind zu richten an die: Zahntechniker-Innung Berlin-Brandenburg Alt-Moabit 105, 10559 Berlin. · Im Wettbewerbszeitraum eingereichte themengerechte Beiträge werden in einer monatlichen "Hitliste" im Internet veröffentlicht. · Eine unabhängige Jury wählt aus den im Internet veröffentlichten Beiträgen im Januar 1999 die besten Arbeiten zur Prämierung aus. Die Prämierung erfolgt im Februar 1999. · Die zwölf besten Beiträge werden prämiert mit: 1. Preis 3.000,00 DM 2. Preis 2.000,00 DM 3. Preis 1.000,00 DM 4.-12. Preis 500,00 DM · Die Preisträger und ihre Beiträge werden von Februar bis Dezember 1999 im Internet veröffentlicht. · Die zwölf prämierten Beiträge werden voraussichtlich in einem repräsentativen Wandkalender veröffentlicht. · Sämtliche eingesandten Beiträge können für Werbeartikel, wie Broschüren und Plakate durch die Zahntechniker-Innung Berlin-Brandenburg genutzt werden. Teilnehmen kann jede Person mit beliebig vielen Beiträgen. Mit der Einsendung seines Wettbewerbsbeitrags erklärt der Teilnehmer sein Einverständnis mit den Teilnahmebedingungen. Die Arbeiten sollten in der Regel im Format DIN A4 (210 x 297 mm) sein, jedoch nicht größer als DIN A3 (297 x 420 mm). Sämtliche Beiträge müssen gut leserlich mit Namen, Adresse, Beruf und Altersangabe versehen sein. Zahntechniker-Innung Berlin-Brandenburg Graphic and Cartoon Competition of the Zahntechniker-Innung Berlin-Brandenburg on the topic "For teeth there is no alternative. But denture!" In 1996/97 we launched a big photo and idea competition. The motto was: "With healthy and beautiful teeth you feel good and like laughing". More than 1000 participants sent in their contributions. The best of them got prizes and can be found in the internet (<A HREF="http://www.zibb.de">http://www.zibb.de</A>) under the heading "Foto- und Ideenwettbewerb". We want to continue this successful campaign with our new Graphic and Cartoon Competition. Join the contest! Conditions of participation · We are looking for illustrations and cartoons, created by the participants, on the subject of the competition. · Contributions can be sent in from1st April to 30th November 1998. The address is: Zahntechniker-Innung Berlin-Brandenburg (Dental Technicians Corporation Berlin- Brandenburg) Alt-Moabit 105, 10559 Berlin Germany · All contributions coming in until the deadline will be published in our monthly "Top 10 ..." in the Internet · An independent jury will chose the best works out of those published in the internet in January 1999. The prizes will be awarded in February 1999. · Twelve winning contributions will be awarded with: · 1st prize 3.000,00 DM 2nd prize 2.000,00 DM 3rd prize 1.000,00 DM 4th to 12th prize 500,00 DM · The winners and their works will be published in the Internet from February to December 1999. · The twelve wining contributions will probably be published in a representative calendar. · All contributions can be used for advertising, i.e. for brochures and posters by the Zahntechniker-Innung Berlin-Brandenburg. Anyone can participate with an optional number of pieces of work. By sending in his/her contribution the participant agrees with the conditions of participation. The works should have the regular format DIN A4 (210 x 297 mm) but they should not exceed format DIN A3 (297 X 420 mm). Name, address, occupation and age of the participant are supposed to be on the piece in a readable condition. Concours de l'art graphique et de la caricature organise par la chambre des Zahntechniker-Innung Berlin-Brandenburg sur le sujet ""Il n' y a pas d'alternative aux dents, que des substituts!" En 1996/97 nous avons organisé un grand concours créatif et photographique sur le sujet "Celui qui a des dents saines et belles se sent bien et aime rire". Il y avait plus de 1000 participants. Les meilleurs résultats ont accordé un prix et ils ont été publiés sur l'Internet ( <A HREF="http://www.zibb.de">http://www.zibb.de</A>) sous la rubrique de "Concours créatif et photographique". À cause du succès de cette action nous voulons continuer avec notre nouveau concours graphique et de la caricature. Participez-y! Bonne chance! Conditions de participation · Nous cherchons des graphiques et caricatures crées au sujet du concours. · La date limite des envois est le 30 novembre 1998. Adressez vos graphiques et caricatures à: Zahntechniker-Innung Berlin-Brandenburg (Chambre des parodontistes Berlin-Brandenburg) Alt-Moabit 105, 10559 Berlin. Allemagne · Pendant la période du concours on va publier sur l'Internet les favorites mensuelles. · En janvier 1999 un jury indépendant va choisir les meilleurs résultats de toutes les publications sur l'Internet. L'attribution des prix aura lieu en février 1999. · Les douze meilleurs participants primeront: · 1. prix 3.000,00 DM 2. prix 2.000,00 DM 3. prix 1.000,00 DM 4.-12. prix 500,00 DM · Du février au décembre 1999 les lauréats et leurs créations seront publiés á l'Internet et de surcroît à un calendrier mural représentatif. · Toutes les graphiques et caricatures peuvent être utilisés aux articles de publicité comme brochures et affiches par la chambre des mécanicien-dentistes Berlin-Brandenburg. Chacun peut y participer avec un nombre illimité de propositions. Par l'envoi des créations chaque participant déclare son accord aux conditions de la participation. Le format des travaux devrait être à préférence DIN A 4 (210 sur 297 mm) et pas dépasser le format DIN A 3 (297 sur 420 mm). Indiquez s.v.p. toujours votre nom, l'adresse, la profession et l'âge. (Chambre des parodontistes Berlin-Brandenburg) Zahntechniker-Innung Berlin-Brandenburg

1 0

Graphic and Cartoon Competition
by MPaul5045＠aol.com July 31, 1998

July 31, 1998

Graphic and Cartoon Competition Concours de l'art graphique et de la caricature Grafik- und Karikaturenwettbewerb <A HREF="http://www.zibb.de">http://www.zibb.de</A> Grafik- und Karikaturenwettbewerb der Zahntechniker-Innung Berlin-Brandenburg zum Thema "Für Zähne gibt es keine Alternative. Aber Ersatz!" Unter dem Motto "Wer gesunde und schöne Zähne hat, fühlt sich wohl und lacht gern" veranstalteten wir 1996/97 einen großen Foto- und Ideenwettbewerb. Weit über 1000 Teilnehmer reichten hierzu ihre Beiträge ein. Die Besten wurden prämiert und sind im Internet (<A HREF="http://www.zibb.de">http://www.zibb.de </A>) unter der Rubrik "Foto- und Ideenwettbewerb" dokumentiert. Mit unserem neuen Grafik- und Karikaturenwettbewerb wollen wir an diese erfolgreiche Aktion anknüpfen. Machen Sie mit! Teilnahmebedingungen · Gesucht werden zum Wettbewerbsthema selbst gestaltete Grafiken und Karikaturen. · Wettbewerbsbeiträge können eingereicht werden in der Zeit vom 1. April bis 30. November 1998. Sie sind zu richten an die: Zahntechniker-Innung Berlin-Brandenburg Alt-Moabit 105, 10559 Berlin. · Im Wettbewerbszeitraum eingereichte themengerechte Beiträge werden in einer monatlichen "Hitliste" im Internet veröffentlicht. · Eine unabhängige Jury wählt aus den im Internet veröffentlichten Beiträgen im Januar 1999 die besten Arbeiten zur Prämierung aus. Die Prämierung erfolgt im Februar 1999. · Die zwölf besten Beiträge werden prämiert mit: 1. Preis 3.000,00 DM 2. Preis 2.000,00 DM 3. Preis 1.000,00 DM 4.-12. Preis 500,00 DM · Die Preisträger und ihre Beiträge werden von Februar bis Dezember 1999 im Internet veröffentlicht. · Die zwölf prämierten Beiträge werden voraussichtlich in einem repräsentativen Wandkalender veröffentlicht. · Sämtliche eingesandten Beiträge können für Werbeartikel, wie Broschüren und Plakate durch die Zahntechniker-Innung Berlin-Brandenburg genutzt werden. Teilnehmen kann jede Person mit beliebig vielen Beiträgen. Mit der Einsendung seines Wettbewerbsbeitrags erklärt der Teilnehmer sein Einverständnis mit den Teilnahmebedingungen. Die Arbeiten sollten in der Regel im Format DIN A4 (210 x 297 mm) sein, jedoch nicht größer als DIN A3 (297 x 420 mm). Sämtliche Beiträge müssen gut leserlich mit Namen, Adresse, Beruf und Altersangabe versehen sein. Zahntechniker-Innung Berlin-Brandenburg Graphic and Cartoon Competition of the Zahntechniker-Innung Berlin-Brandenburg on the topic "For teeth there is no alternative. But denture!" In 1996/97 we launched a big photo and idea competition. The motto was: "With healthy and beautiful teeth you feel good and like laughing". More than 1000 participants sent in their contributions. The best of them got prizes and can be found in the internet (<A HREF="http://www.zibb.de">http://www.zibb.de</A>) under the heading "Foto- und Ideenwettbewerb". We want to continue this successful campaign with our new Graphic and Cartoon Competition. Join the contest! Conditions of participation · We are looking for illustrations and cartoons, created by the participants, on the subject of the competition. · Contributions can be sent in from1st April to 30th November 1998. The address is: Zahntechniker-Innung Berlin-Brandenburg (Dental Technicians Corporation Berlin- Brandenburg) Alt-Moabit 105, 10559 Berlin Germany · All contributions coming in until the deadline will be published in our monthly "Top 10 ..." in the Internet · An independent jury will chose the best works out of those published in the internet in January 1999. The prizes will be awarded in February 1999. · Twelve winning contributions will be awarded with: · 1st prize 3.000,00 DM 2nd prize 2.000,00 DM 3rd prize 1.000,00 DM 4th to 12th prize 500,00 DM · The winners and their works will be published in the Internet from February to December 1999. · The twelve wining contributions will probably be published in a representative calendar. · All contributions can be used for advertising, i.e. for brochures and posters by the Zahntechniker-Innung Berlin-Brandenburg. Anyone can participate with an optional number of pieces of work. By sending in his/her contribution the participant agrees with the conditions of participation. The works should have the regular format DIN A4 (210 x 297 mm) but they should not exceed format DIN A3 (297 X 420 mm). Name, address, occupation and age of the participant are supposed to be on the piece in a readable condition. Concours de l'art graphique et de la caricature organise par la chambre des Zahntechniker-Innung Berlin-Brandenburg sur le sujet ""Il n' y a pas d'alternative aux dents, que des substituts!" En 1996/97 nous avons organisé un grand concours créatif et photographique sur le sujet "Celui qui a des dents saines et belles se sent bien et aime rire". Il y avait plus de 1000 participants. Les meilleurs résultats ont accordé un prix et ils ont été publiés sur l'Internet ( <A HREF="http://www.zibb.de">http://www.zibb.de</A>) sous la rubrique de "Concours créatif et photographique". À cause du succès de cette action nous voulons continuer avec notre nouveau concours graphique et de la caricature. Participez-y! Bonne chance! Conditions de participation · Nous cherchons des graphiques et caricatures crées au sujet du concours. · La date limite des envois est le 30 novembre 1998. Adressez vos graphiques et caricatures à: Zahntechniker-Innung Berlin-Brandenburg (Chambre des parodontistes Berlin-Brandenburg) Alt-Moabit 105, 10559 Berlin. Allemagne · Pendant la période du concours on va publier sur l'Internet les favorites mensuelles. · En janvier 1999 un jury indépendant va choisir les meilleurs résultats de toutes les publications sur l'Internet. L'attribution des prix aura lieu en février 1999. · Les douze meilleurs participants primeront: · 1. prix 3.000,00 DM 2. prix 2.000,00 DM 3. prix 1.000,00 DM 4.-12. prix 500,00 DM · Du février au décembre 1999 les lauréats et leurs créations seront publiés á l'Internet et de surcroît à un calendrier mural représentatif. · Toutes les graphiques et caricatures peuvent être utilisés aux articles de publicité comme brochures et affiches par la chambre des mécanicien-dentistes Berlin-Brandenburg. Chacun peut y participer avec un nombre illimité de propositions. Par l'envoi des créations chaque participant déclare son accord aux conditions de la participation. Le format des travaux devrait être à préférence DIN A 4 (210 sur 297 mm) et pas dépasser le format DIN A 3 (297 sur 420 mm). Indiquez s.v.p. toujours votre nom, l'adresse, la profession et l'âge. (Chambre des parodontistes Berlin-Brandenburg) Zahntechniker-Innung Berlin-Brandenburg

1 0

General information
by iers＠hpvlbi.obspm.fr July 30, 1998

July 30, 1998

To IERS users >From: IERS Central Bureau (iers(a)obspm.fr) Subjects : New format in the permanent EOP(IERS)97 C 04 solutions for 1998 : Removal of the previous EOP(IERS) C01, C01, C03 and C04 in CB ftp Dear Colleagues, Please note the following changes in the EOP solutions of the IERS Central Bureau: 1 - New format in the permanent EOP(IERS)97 C 04 solutions for 1998 To align to the format used by USNO VLBI analysis center and those recently adopted by the IGS, the IERS Central Bureau will adopt a new format with an extra digit for polar motion and UT/LOD. This change starting from July 1998 will be first applied to the permanent EOP(IERS)97 C 04 for 1998 and the combined IERS/CB GPS solution (IERS)97 P 01. It will progressively be applied for other previous years of C04 and also to all combined solutions C01, C02 and C03. The new format for the C04 solution is the following: => FORMAT(2X,A4,I3,2X,I5,2F9.6,F10.7,2X,F10.7,2X,2F9.5) Note: The precision in the determination of Earth Orientation Parameters has dramatically increased over the latter few years thanks to the improvement in techniques and in data analysis. The IGS community has recently decided to add an extra digit to Polar Motion and UT/LOD estimates primarily for the sake of meaningful formal solution sigmas. GPS Analysis centers are progressively introducing this new format. It is clear however that the accuracy of 1 micro-arcsecond in polar motion and 0.1 micro-second for UT/LOD (corresponding to 0.3 mm on the earth surface) is not yet reached. 2 - EOP(IERS) C 01, C02, C03 and C04 which were the current solutions before the adoption of the "1997 system" (see gazettes 8 and 16) will be removed from the web/ftp site on 1 September, 1998. These series will still be available on request (iers(a)obspm.fr)

1 0

t z mailing list
by Pollard, Richard July 27, 1998

July 27, 1998

Please add subscription for rpollard(a)fullerton.edu

1 0

Re: FW: Order of listing month, day, and year in local date formats.
by Ulrich Drepper July 23, 1998

July 23, 1998

"Olson, Arthur David (NCI)" <olsona(a)dc37a.nci.nih.gov> writes: > Do you know where I can get a list of the local year-month-day > orders used in each country? For example, the U.S. uses > month-day-year order. The POSIX locale desriptions ftp://dkuug.dk/i18n/WG15-collection contain specification for many countries and in the LC_TIME category descriptions the field named d_fmt specifies a strftime format to print dates. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------

1 0

FW: Order of listing month, day, and year in local date formats.
by Olson, Arthur David (NCI) July 23, 1998

July 23, 1998

Note that Dave Fabian is not on the time zone mailing list; please ensure that Dave receives any replies. --ado -----Original Message----- From: Dave & Betty Fabian [SMTP:dfabian@sprynet.com] Sent: Saturday, July 18, 1998 3:58 AM To: Olson, Arthur David (NCI) Subject: Order of listing month, day, and year in local date formats. Dear Mr. Olson, Do you know where I can get a list of the local year-month-day orders used in each country? For example, the U.S. uses month-day-year order. Thank you, Dave Fabian

2 1

RE: Order of listing month, day, and year in local date formats.
by Christophe PIERRET July 23, 1998

July 23, 1998

First of all , be aware of that : ================================= There can be more than one set of cultural convention in use in one country ! I don't know if Tibetans and Chinese use the same set of conventions ... even if they live in the same country. Proposed solutions : ==================== The easy way is to use your system's locale. In the C language, you could use the Windows NLS API or the C locale API to obtain these informations. You can also check POSIX locale definition file in the LC_TIME category. There is a repository of such files at: ftp://dkuug.dk/i18n/WG15-collection/locales/ You can also make a poll on the internet news ;-) For Unix folks , I included the results of the second program (using windows NLS API) in the mail... Hope it helps ! ______________________________________________________ Christophe Pierret Software Development Engineer Windows Product Group Professional E-mail: cpierret(a)businessobjects.com Business Objects S.A. 1, square Chaptal, 92309 Levallois-Perret, FRANCE http://www.businessobjects.com ______ /_/_/_/| /_/_/_/ | /_/_/_/ | |_|_|_|Cube Team |_|_|_| / |_|_|_|/ Quick and untested example using the C locale (Unix like): ========================================================== #include <time.h> #include <locale.h> #define MAX_RESULT 512 void PrintDefaultDateFormat(char * localeName) { char result[MAX_RESULT]; struct tm* pMyTM; time_t ltime; time(&ltime); pMyTM = gmtime(ltime); setlocale(LC_TIME,localeName); strftime(result,MAX_RESULT,"%x",pMyTM); /* %x is default locale date format */ printf("Current date in locale %s is %s\n",localeName,result); }; Tested example using the Windows NLS API: ======================================= Using the Windows NLS API would give something like the following C program : #include <time.h> #include <stdio.h> #include <locale.h> #include <windows.h> #include <winnls.h> #include <winnt.h> typedef struct _myLocale_t { LCID locale; char * name; } myLocale_t; myLocale_t winLocales[]= { { MAKELCID(MAKELANGID(LANG_AFRIKAANS,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_AFRIKAANS" }, { MAKELCID(MAKELANGID(LANG_ALBANIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_ALBANIAN" }, { MAKELCID(MAKELANGID(LANG_BASQUE,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_BASQUE" }, { MAKELCID(MAKELANGID(LANG_BELARUSIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_BELARUSIAN" }, { MAKELCID(MAKELANGID(LANG_BULGARIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_BULGARIAN" }, { MAKELCID(MAKELANGID(LANG_CATALAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_CATALAN" }, { MAKELCID(MAKELANGID(LANG_CROATIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_CROATIAN" }, { MAKELCID(MAKELANGID(LANG_CZECH,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_CZECH" }, { MAKELCID(MAKELANGID(LANG_DANISH,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_DANISH" }, { MAKELCID(MAKELANGID(LANG_ESTONIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_ESTONIAN" }, { MAKELCID(MAKELANGID(LANG_FAEROESE,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_FAEROESE" }, { MAKELCID(MAKELANGID(LANG_FARSI,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_FARSI" }, { MAKELCID(MAKELANGID(LANG_FINNISH,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_FINNISH" }, { MAKELCID(MAKELANGID(LANG_GREEK,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_GREEK" }, { MAKELCID(MAKELANGID(LANG_HEBREW,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_HEBREW" }, { MAKELCID(MAKELANGID(LANG_HUNGARIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_HUNGARIAN" }, { MAKELCID(MAKELANGID(LANG_ICELANDIC,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_ICELANDIC" }, { MAKELCID(MAKELANGID(LANG_INDONESIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_INDONESIAN" }, { MAKELCID(MAKELANGID(LANG_JAPANESE,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_JAPANESE" }, { MAKELCID(MAKELANGID(LANG_LATVIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_LATVIAN" }, { MAKELCID(MAKELANGID(LANG_LITHUANIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_LITHUANIAN" }, { MAKELCID(MAKELANGID(LANG_NORWEGIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_NORWEGIAN" }, { MAKELCID(MAKELANGID(LANG_POLISH,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_POLISH" }, { MAKELCID(MAKELANGID(LANG_ROMANIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_ROMANIAN" }, { MAKELCID(MAKELANGID(LANG_RUSSIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_RUSSIAN" }, { MAKELCID(MAKELANGID(LANG_SLOVAK,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_SLOVAK" }, { MAKELCID(MAKELANGID(LANG_SLOVENIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_SLOVENIAN" }, { MAKELCID(MAKELANGID(LANG_THAI,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_THAI" }, { MAKELCID(MAKELANGID(LANG_TURKISH,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_TURKISH" }, { MAKELCID(MAKELANGID(LANG_UKRAINIAN,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_UKRAINIAN" }, { MAKELCID(MAKELANGID(LANG_VIETNAMESE,SUBLANG_NEUTRAL),SORT_DEFAULT) , "LANG_VIETNAMESE" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_SAUDI_ARABIA),SORT_DEFAUL T) , "SUBLANG_ARABIC_SAUDI_ARABIA" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_IRAQ),SORT_DEFAULT) , "SUBLANG_ARABIC_IRAQ" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_EGYPT),SORT_DEFAULT) , "SUBLANG_ARABIC_EGYPT" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_LIBYA),SORT_DEFAULT) , "SUBLANG_ARABIC_LIBYA" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_ALGERIA),SORT_DEFAULT) , "SUBLANG_ARABIC_ALGERIA" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_MOROCCO),SORT_DEFAULT) , "SUBLANG_ARABIC_MOROCCO" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_TUNISIA),SORT_DEFAULT) , "SUBLANG_ARABIC_TUNISIA" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_OMAN),SORT_DEFAULT) , "SUBLANG_ARABIC_OMAN" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_YEMEN),SORT_DEFAULT) , "SUBLANG_ARABIC_YEMEN" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_SYRIA),SORT_DEFAULT) , "SUBLANG_ARABIC_SYRIA" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_JORDAN),SORT_DEFAULT) , "SUBLANG_ARABIC_JORDAN" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_LEBANON),SORT_DEFAULT) , "SUBLANG_ARABIC_LEBANON" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_KUWAIT),SORT_DEFAULT) , "SUBLANG_ARABIC_KUWAIT" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_UAE),SORT_DEFAULT) , "SUBLANG_ARABIC_UAE" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_BAHRAIN),SORT_DEFAULT) , "SUBLANG_ARABIC_BAHRAIN" }, { MAKELCID(MAKELANGID(LANG_ARABIC,SUBLANG_ARABIC_QATAR),SORT_DEFAULT) , "SUBLANG_ARABIC_QATAR" }, { MAKELCID(MAKELANGID(LANG_CHINESE,SUBLANG_CHINESE_TRADITIONAL),SORT_DEFAU LT) , "SUBLANG_CHINESE_TRADITIONAL" }, { MAKELCID(MAKELANGID(LANG_CHINESE,SUBLANG_CHINESE_SIMPLIFIED),SORT_DEFAUL T) , "SUBLANG_CHINESE_SIMPLIFIED" }, { MAKELCID(MAKELANGID(LANG_CHINESE,SUBLANG_CHINESE_HONGKONG),SORT_DEFAULT) , "SUBLANG_CHINESE_HONGKONG" }, { MAKELCID(MAKELANGID(LANG_CHINESE,SUBLANG_CHINESE_SINGAPORE),SORT_DEFAULT ) , "SUBLANG_CHINESE_SINGAPORE" }, { MAKELCID(MAKELANGID(LANG_DUTCH,SUBLANG_DUTCH),SORT_DEFAULT) , "SUBLANG_DUTCH" }, { MAKELCID(MAKELANGID(LANG_DUTCH,SUBLANG_DUTCH_BELGIAN),SORT_DEFAULT) , "SUBLANG_DUTCH_BELGIAN" }, { MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_US),SORT_DEFAULT) , "SUBLANG_ENGLISH_US" }, { MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_UK),SORT_DEFAULT) , "SUBLANG_ENGLISH_UK" }, { MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_AUS),SORT_DEFAULT) , "SUBLANG_ENGLISH_AUS" }, { MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_CAN),SORT_DEFAULT) , "SUBLANG_ENGLISH_CAN" }, { MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_NZ),SORT_DEFAULT) , "SUBLANG_ENGLISH_NZ" }, { MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_EIRE),SORT_DEFAULT) , "SUBLANG_ENGLISH_EIRE" }, { MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_SOUTH_AFRICA),SORT_DEFA ULT) , "SUBLANG_ENGLISH_SOUTH_AFRICA" }, { MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_JAMAICA),SORT_DEFAULT) , "SUBLANG_ENGLISH_JAMAICA" }, { MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_CARIBBEAN),SORT_DEFAULT ) , "SUBLANG_ENGLISH_CARIBBEAN" }, { MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_BELIZE),SORT_DEFAULT) , "SUBLANG_ENGLISH_BELIZE" }, { MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_TRINIDAD),SORT_DEFAULT) , "SUBLANG_ENGLISH_TRINIDAD" }, { MAKELCID(MAKELANGID(LANG_FRENCH,SUBLANG_FRENCH),SORT_DEFAULT) , "SUBLANG_FRENCH" }, { MAKELCID(MAKELANGID(LANG_FRENCH,SUBLANG_FRENCH_BELGIAN),SORT_DEFAULT) , "SUBLANG_FRENCH_BELGIAN" }, { MAKELCID(MAKELANGID(LANG_FRENCH,SUBLANG_FRENCH_CANADIAN),SORT_DEFAULT) , "SUBLANG_FRENCH_CANADIAN" }, { MAKELCID(MAKELANGID(LANG_FRENCH,SUBLANG_FRENCH_SWISS),SORT_DEFAULT) , "SUBLANG_FRENCH_SWISS" }, { MAKELCID(MAKELANGID(LANG_FRENCH,SUBLANG_FRENCH_LUXEMBOURG),SORT_DEFAULT) , "SUBLANG_FRENCH_LUXEMBOURG" }, { MAKELCID(MAKELANGID(LANG_GERMAN,SUBLANG_GERMAN),SORT_DEFAULT) , "SUBLANG_GERMAN" }, { MAKELCID(MAKELANGID(LANG_GERMAN,SUBLANG_GERMAN_SWISS),SORT_DEFAULT) , "SUBLANG_GERMAN_SWISS" }, { MAKELCID(MAKELANGID(LANG_GERMAN,SUBLANG_GERMAN_AUSTRIAN),SORT_DEFAULT) , "SUBLANG_GERMAN_AUSTRIAN" }, { MAKELCID(MAKELANGID(LANG_GERMAN,SUBLANG_GERMAN_LUXEMBOURG),SORT_DEFAULT) , "SUBLANG_GERMAN_LUXEMBOURG" }, { MAKELCID(MAKELANGID(LANG_GERMAN,SUBLANG_GERMAN_LIECHTENSTEIN),SORT_DEFAU LT) , "SUBLANG_GERMAN_LIECHTENSTEIN" }, { MAKELCID(MAKELANGID(LANG_ITALIAN,SUBLANG_ITALIAN),SORT_DEFAULT) , "SUBLANG_ITALIAN" }, { MAKELCID(MAKELANGID(LANG_ITALIAN,SUBLANG_ITALIAN_SWISS),SORT_DEFAULT) , "SUBLANG_ITALIAN_SWISS" }, { MAKELCID(MAKELANGID(LANG_KOREAN,SUBLANG_KOREAN),SORT_DEFAULT) , "SUBLANG_KOREAN" }, { MAKELCID(MAKELANGID(LANG_KOREAN,SUBLANG_KOREAN_JOHAB),SORT_DEFAULT) , "SUBLANG_KOREAN_JOHAB" }, { MAKELCID(MAKELANGID(LANG_NORWEGIAN,SUBLANG_NORWEGIAN_BOKMAL),SORT_DEFAUL T) , "SUBLANG_NORWEGIAN_BOKMAL" }, { MAKELCID(MAKELANGID(LANG_NORWEGIAN,SUBLANG_NORWEGIAN_NYNORSK),SORT_DEFAU LT) , "SUBLANG_NORWEGIAN_NYNORSK" }, { MAKELCID(MAKELANGID(LANG_PORTUGUESE,SUBLANG_PORTUGUESE),SORT_DEFAULT) , "SUBLANG_PORTUGUESE" }, { MAKELCID(MAKELANGID(LANG_PORTUGUESE,SUBLANG_PORTUGUESE_BRAZILIAN),SORT_D EFAULT) , "SUBLANG_PORTUGUESE_BRAZILIAN" }, { MAKELCID(MAKELANGID(LANG_SERBIAN,SUBLANG_SERBIAN_LATIN),SORT_DEFAULT) , "SUBLANG_SERBIAN_LATIN" }, { MAKELCID(MAKELANGID(LANG_SERBIAN,SUBLANG_SERBIAN_CYRILLIC),SORT_DEFAULT) , "SUBLANG_SERBIAN_CYRILLIC" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH),SORT_DEFAULT) , "SUBLANG_SPANISH" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_MEXICAN),SORT_DEFAULT) , "SUBLANG_SPANISH_MEXICAN" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_MODERN),SORT_DEFAULT) , "SUBLANG_SPANISH_MODERN" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_GUATEMALA),SORT_DEFAULT ) , "SUBLANG_SPANISH_GUATEMALA" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_COSTA_RICA),SORT_DEFAUL T) , "SUBLANG_SPANISH_COSTA_RICA" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_PANAMA),SORT_DEFAULT) , "SUBLANG_SPANISH_PANAMA" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_DOMINICAN_REPUBLIC),SOR T_DEFAULT) , "SUBLANG_SPANISH_DOMINICAN_REPUBLIC" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_VENEZUELA),SORT_DEFAULT ) , "SUBLANG_SPANISH_VENEZUELA" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_COLOMBIA),SORT_DEFAULT) , "SUBLANG_SPANISH_COLOMBIA" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_PERU),SORT_DEFAULT) , "SUBLANG_SPANISH_PERU" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_ARGENTINA),SORT_DEFAULT ) , "SUBLANG_SPANISH_ARGENTINA" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_ECUADOR),SORT_DEFAULT) , "SUBLANG_SPANISH_ECUADOR" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_CHILE),SORT_DEFAULT) , "SUBLANG_SPANISH_CHILE" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_URUGUAY),SORT_DEFAULT) , "SUBLANG_SPANISH_URUGUAY" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_PARAGUAY),SORT_DEFAULT) , "SUBLANG_SPANISH_PARAGUAY" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_BOLIVIA),SORT_DEFAULT) , "SUBLANG_SPANISH_BOLIVIA" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_EL_SALVADOR),SORT_DEFAU LT) , "SUBLANG_SPANISH_EL_SALVADOR" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_HONDURAS),SORT_DEFAULT) , "SUBLANG_SPANISH_HONDURAS" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_NICARAGUA),SORT_DEFAULT ) , "SUBLANG_SPANISH_NICARAGUA" }, { MAKELCID(MAKELANGID(LANG_SPANISH,SUBLANG_SPANISH_PUERTO_RICO),SORT_DEFAU LT) , "SUBLANG_SPANISH_PUERTO_RICO" }, { MAKELCID(MAKELANGID(LANG_SWEDISH,SUBLANG_SWEDISH),SORT_DEFAULT) , "SUBLANG_SWEDISH" }, { MAKELCID(MAKELANGID(LANG_SWEDISH,SUBLANG_SWEDISH_FINLAND),SORT_DEFAULT) , "SUBLANG_SWEDISH_FINLAND" }, { 0 , 0 } }; void HandleError(char* name) { DWORD err=GetLastError(); switch(err) { case ERROR_INSUFFICIENT_BUFFER: fprintf(stderr,"Insufficient buffer\n"); exit(err); break; case ERROR_INVALID_FLAGS: fprintf(stderr,"Invalid flags\n"); exit(err); break; case ERROR_INVALID_PARAMETER: fprintf(stderr,"Invalid parameter for locale %s\n",name); break; default: fprintf(stderr,"Unknown error\n"); exit(err); break; } fflush(stderr); }; int main(int argc,char* argv[]) { LCID localeId; int nBytes; char * pData; int i; char * str[3]; int iStr = 0; int iBytes; for ( i = 0; winLocales[i].name!=0 ; ++i) { int dayFound = 0; int monthFound = 0; int yearFound = 0; localeId = winLocales[i].locale; nBytes = GetLocaleInfo( localeId, // locale identifier LOCALE_SSHORTDATE, // type of information NULL, // address of buffer for information 0 // size of buffer ); if (nBytes==0) { HandleError(winLocales[i].name); continue; }; pData = (char*)malloc(nBytes); if ( GetLocaleInfo( localeId, // locale identifier LOCALE_SSHORTDATE, // type of information pData, // address of buffer for information nBytes // size of buffer ) ==0) { HandleError(winLocales[i].name); free(pData); continue; } str[0]=str[1]=str[2]=""; for (iBytes=0, iStr=0 ; iBytes != nBytes ; ++iBytes) { switch (pData[iBytes]) { case 'd': case 'D': if (!dayFound) { dayFound = !dayFound; str[iStr++] = "Day"; } break; case 'm': case 'M': if (!monthFound) { monthFound = !monthFound; str[iStr++] = "Month"; } break; case 'y': case 'Y': if (!yearFound) { yearFound = !yearFound; str[iStr++] = "Year"; } break; } } printf("In locale %s , format is %s/%s/%s\n",winLocales[i].name,str[0],str[1],str[2]); free(pData); }; return 0; } Here are the result on windows NT 4.0 ( my machine !): In locale LANG_AFRIKAANS , format is Year/Month/Day In locale LANG_ALBANIAN , format is Year/Month/Day In locale LANG_BASQUE , format is Year/Month/Day In locale LANG_BELARUSIAN , format is Day/Month/Year In locale LANG_BULGARIAN , format is Day/Month/Year In locale LANG_CATALAN , format is Day/Month/Year In locale LANG_CROATIAN , format is Year/Month/Day In locale LANG_CZECH , format is Day/Month/Year In locale LANG_DANISH , format is Day/Month/Year In locale LANG_ESTONIAN , format is Day/Month/Year In locale LANG_FAEROESE , format is Day/Month/Year In locale LANG_FARSI , format is Day/Month/Year In locale LANG_FINNISH , format is Day/Month/Year In locale LANG_GREEK , format is Day/Month/Year In locale LANG_HEBREW , format is Day/Month/Year In locale LANG_HUNGARIAN , format is Year/Month/Day In locale LANG_ICELANDIC , format is Day/Month/Year In locale LANG_INDONESIAN , format is Day/Month/Year In locale LANG_JAPANESE , format is Year/Month/Day In locale LANG_LATVIAN , format is Year/Month/Day In locale LANG_LITHUANIAN , format is Year/Month/Day In locale LANG_NORWEGIAN , format is Day/Month/Year In locale LANG_POLISH , format is Year/Month/Day In locale LANG_ROMANIAN , format is Day/Month/Year In locale LANG_RUSSIAN , format is Day/Month/Year In locale LANG_SLOVAK , format is Day/Month/Year In locale LANG_SLOVENIAN , format is Day/Month/Year In locale LANG_TURKISH , format is Day/Month/Year In locale LANG_UKRAINIAN , format is Day/Month/Year In locale SUBLANG_ARABIC_SAUDI_ARABIA , format is Day/Month/Year In locale SUBLANG_ARABIC_IRAQ , format is Day/Month/Year In locale SUBLANG_ARABIC_EGYPT , format is Day/Month/Year In locale SUBLANG_ARABIC_LIBYA , format is Day/Month/Year In locale SUBLANG_ARABIC_ALGERIA , format is Day/Month/Year In locale SUBLANG_ARABIC_MOROCCO , format is Day/Month/Year In locale SUBLANG_ARABIC_TUNISIA , format is Day/Month/Year In locale SUBLANG_ARABIC_OMAN , format is Day/Month/Year In locale SUBLANG_ARABIC_YEMEN , format is Day/Month/Year In locale SUBLANG_ARABIC_SYRIA , format is Day/Month/Year In locale SUBLANG_ARABIC_JORDAN , format is Day/Month/Year In locale SUBLANG_ARABIC_LEBANON , format is Day/Month/Year In locale SUBLANG_ARABIC_KUWAIT , format is Day/Month/Year In locale SUBLANG_ARABIC_UAE , format is Day/Month/Year In locale SUBLANG_ARABIC_BAHRAIN , format is Day/Month/Year In locale SUBLANG_ARABIC_QATAR , format is Day/Month/Year In locale SUBLANG_CHINESE_TRADITIONAL , format is Year/Month/Day In locale SUBLANG_CHINESE_SIMPLIFIED , format is Year/Month/Day In locale SUBLANG_CHINESE_HONGKONG , format is Day/Month/Year In locale SUBLANG_CHINESE_SINGAPORE , format is Day/Month/Year In locale SUBLANG_DUTCH , format is Day/Month/Year In locale SUBLANG_DUTCH_BELGIAN , format is Day/Month/Year In locale SUBLANG_ENGLISH_US , format is Month/Day/Year In locale SUBLANG_ENGLISH_UK , format is Day/Month/Year In locale SUBLANG_ENGLISH_AUS , format is Day/Month/Year In locale SUBLANG_ENGLISH_CAN , format is Day/Month/Year In locale SUBLANG_ENGLISH_NZ , format is Day/Month/Year In locale SUBLANG_ENGLISH_EIRE , format is Day/Month/Year In locale SUBLANG_ENGLISH_SOUTH_AFRICA , format is Year/Month/Day In locale SUBLANG_ENGLISH_JAMAICA , format is Day/Month/Year In locale SUBLANG_ENGLISH_CARIBBEAN , format is Month/Day/Year In locale SUBLANG_ENGLISH_BELIZE , format is Day/Month/Year In locale SUBLANG_ENGLISH_TRINIDAD , format is Day/Month/Year In locale SUBLANG_FRENCH , format is Day/Month/Year In locale SUBLANG_FRENCH_BELGIAN , format is Day/Month/Year In locale SUBLANG_FRENCH_CANADIAN , format is Year/Month/Day In locale SUBLANG_FRENCH_SWISS , format is Day/Month/Year In locale SUBLANG_FRENCH_LUXEMBOURG , format is Day/Month/Year In locale SUBLANG_GERMAN , format is Day/Month/Year In locale SUBLANG_GERMAN_SWISS , format is Day/Month/Year In locale SUBLANG_GERMAN_AUSTRIAN , format is Day/Month/Year In locale SUBLANG_GERMAN_LUXEMBOURG , format is Day/Month/Year In locale SUBLANG_GERMAN_LIECHTENSTEIN , format is Day/Month/Year In locale SUBLANG_ITALIAN , format is Day/Month/Year In locale SUBLANG_ITALIAN_SWISS , format is Day/Month/Year In locale SUBLANG_KOREAN , format is Year/Month/Day In locale SUBLANG_NORWEGIAN_BOKMAL , format is Day/Month/Year In locale SUBLANG_NORWEGIAN_NYNORSK , format is Day/Month/Year In locale SUBLANG_PORTUGUESE , format is Day/Month/Year In locale SUBLANG_PORTUGUESE_BRAZILIAN , format is Day/Month/Year In locale SUBLANG_SERBIAN_LATIN , format is Day/Month/Year In locale SUBLANG_SERBIAN_CYRILLIC , format is Day/Month/Year In locale SUBLANG_SPANISH , format is Day/Month/Year In locale SUBLANG_SPANISH_MEXICAN , format is Day/Month/Year In locale SUBLANG_SPANISH_MODERN , format is Day/Month/Year In locale SUBLANG_SPANISH_GUATEMALA , format is Day/Month/Year In locale SUBLANG_SPANISH_COSTA_RICA , format is Day/Month/Year In locale SUBLANG_SPANISH_PANAMA , format is Month/Day/Year In locale SUBLANG_SPANISH_DOMINICAN_REPUBLIC , format is Month/Day/Year In locale SUBLANG_SPANISH_VENEZUELA , format is Day/Month/Year In locale SUBLANG_SPANISH_COLOMBIA , format is Day/Month/Year In locale SUBLANG_SPANISH_PERU , format is Day/Month/Year In locale SUBLANG_SPANISH_ARGENTINA , format is Day/Month/Year In locale SUBLANG_SPANISH_ECUADOR , format is Day/Month/Year In locale SUBLANG_SPANISH_CHILE , format is Day/Month/Year In locale SUBLANG_SPANISH_URUGUAY , format is Day/Month/Year In locale SUBLANG_SPANISH_PARAGUAY , format is Day/Month/Year In locale SUBLANG_SPANISH_BOLIVIA , format is Day/Month/Year In locale SUBLANG_SPANISH_EL_SALVADOR , format is Month/Day/Year In locale SUBLANG_SPANISH_HONDURAS , format is Month/Day/Year In locale SUBLANG_SPANISH_NICARAGUA , format is Month/Day/Year In locale SUBLANG_SPANISH_PUERTO , format is Month/Day/Year In locale SUBLANG_SWEDISH , format is Year/Month/Day In locale SUBLANG_SWEDISH_FINLAND , format is Day/Month/Year Et voilà ! > -----Original Message----- > From: Dave & Betty Fabian [SMTP:dfabian@sprynet.com] > Sent: Saturday, July 18, 1998 3:58 AM > To: Olson, Arthur David (NCI) > Subject: Order of listing month, day, and year in local date > formats. > > Dear Mr. Olson, > > Do you know where I can get a list of the local year-month-day orders > used in > each country? > For example, the U.S. uses month-day-year order. > > Thank you, > Dave Fabian >

1 0

date formats
by Markus Kuhn July 23, 1998

July 23, 1998

Dave & Betty Fabian [SMTP:dfabian@sprynet.com] wrote: > Do you know where I can get a list of the local year-month-day orders > used in each country? For example, the U.S. uses month-day-year order. Local date format information is part of the locale data collection on <ftp://dkuug.dk/i18n/locales/> specified in POSIX locale format. More and more users and countries are moving towards the international standard date notation YYYY-MM-DD described on http://www.cl.cam.ac.uk/~mgk25/iso-time.html so you might consider using just this one for simplicity and prevention of confusion. 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

Daylight saving time in selected countries
by Israel Schorr July 22, 1998

July 22, 1998

Dear Sirs, I am looking for the Daylight saving time guidelines (i.e. gneneral role for start date and end date) in selected countries, which I didn't manage to find elsewhere. The countries are: Armenia Belarus Jordan Kazakhstan Kyrgyzastan Latvia Lithuania Moldova Syria Ukraine I would appreciate any information. Thank You Israel Schorr

1 0

joining the tz@elsie.nci.nih.gov mailing list
by Israel Schorr July 22, 1998

July 22, 1998

Dear Sirs, We would highly appreciate if you could join us the the tz(a)elsie.nci.nih.gov mailing list. Thank you very much. Israel Schorr Our E-mail addresses ischorr(a)barakitc.co.il zsilbinger@ barakitc.co.il

1 0

tz problem with GMT leap seconds when the file "backward" is omitted
by Paul Eggert July 20, 1998

July 20, 1998

We discussed the following change as part of a proposed larger patch in late May when talking about the problems with sendmail 8.8.8 in Australia. The rest of the patch was done in a different way, but it seems to me that a fix is still needed for installations that want leap seconds, but also want to omit the links mentioned in the file "backward". Another possible fix would be to modify localtime.c so that it loads "Etc/GMT" rather than "GMT" to get the leap second info for GMT. =================================================================== RCS file: RCS/backward,v retrieving revision 1997.10 retrieving revision 1997.10.1.1 diff -u -r1997.10 -r1997.10.1.1 --- backward 1997/12/11 17:44:35 1997.10 +++ backward 1998/05/24 07:28:25 1997.10.1.1 @@ -38,7 +38,6 @@ Link Africa/Cairo Egypt Link Europe/Dublin Eire Link Europe/London GB -Link Etc/GMT GMT Link Etc/GMT+0 GMT+0 Link Etc/GMT-0 GMT-0 Link Etc/GMT0 GMT0 =================================================================== RCS file: RCS/etcetera,v retrieving revision 1997.11 retrieving revision 1997.11.1.2 diff -u -r1997.11 -r1997.11.1.2 --- etcetera 1997/12/29 14:31:50 1997.11 +++ etcetera 1998/07/20 19:15:00 1997.11.1.2 @@ -10,6 +10,12 @@ Zone Etc/UTC 0 - UTC Zone Etc/UCT 0 - UCT +# The following link uses older naming conventions, +# but it belongs here, not in the file `backward', +# as functions like gmtime load the "GMT" file to handle leap seconds properly. +# We want this to work even on installations that omit the other older names. +Link Etc/GMT GMT + Link Etc/UTC Etc/Universal Link Etc/UTC Etc/Zulu

1 0