Hey there, First of all, I would like to thank you. I have to implement something in JavaScript that uses timezones. However, I am using an older JS version that does not have the flexibility like today’s JS. So I was looking for a repository holding all current timezones and rules for it, rather then me, checking time and again how which timezone is configured 😉 This really could help me. Reading through the files, it sometimes made me chuckle and I was actually surprised how fluent timezones are handled. Changes almost every year… I would like to recommend some improvements. I know you have pretty stable release by now. I am aware that changes probably to the structure might affect a lot of people/projects. However… First of all, a tar.gz is Linux specific. True, you could install additional Windows software. But, that might not go well with customers of mine. I think a ZIP would be acceptable for both worlds. Since I was interested in the repository, I downloaded the “Data only distribution”. I found six files containing the TZ information. And I found 27 files, containing other stuff. Well, there might be three or four files in a grey zone (calendars, backlist…). But I definitely do not consider MAKEFILE and .awk file as part of a “data only distribution”. Maybe move them to a separate folder in the GZ file? Finally, I got one more recommendation/question. I had read the readme file but it didn’t explain the data I saw in the files. It took me a while to understand the concept of the data structure. Some info of what to see in the file, and how to read it would help. And I think the first line of the ZONE definition contains some inconsistency (maybe I still didn’t understand it correctly). Below is a screenshot. See the first line for the zones? It looks mismatched with the New York. The RULE and the [UNTIL] are probably in the wrong column. Format is probably missing. [cid:image002.png@01D674A5.27F71B60] Then I noticed that the open-end validity. For rules it is denoted as “max” and for zones it is just a <blank>. Could we get some consistency here? And finally here comes my question: In the rules, I see in the column several times denoted with a tailing “u” or “s”. I think I read on one occasion that the times are denoted in “standard time”. I do not recall anymore where that was. But regardless, 1. I don’t understand what that “denoted in standard time” would mean 2. I definitely have no clue would the tailing “u”: would imply. [cid:image003.png@01D674A6.99550F50] Can you shed some light on this? Thank you! Not only for an answer but also for researching and compiling this list. Juergen Juergen Naeckel PRINCIPAL ARCHITECT T 617 766 2381 | C 617 775 3874 naeckel@adobe.com [cid:image001.png@01D6749A.D7B33580]
Hi again, I tried to use the data provided in the timezone files. I ran some consistency checks. I think I found some inconsistencies. Zone America/Barbados – has rule BARB, but none of the BARB rules is currently valid. Zone America/Costa_Rica – has rule CR, but none of the CR rules is currently valid.Zone America/El_Salvador – has rule BARB, but none of the rules is currently valid Zone America/Guatemala – has rule Salv, but none of the rules is currently valid Zone America/Tegucigalpa – has rule Hond, but none of the rules is currently valid The zone Africa/Johannesburg uses an undefined rule SA The zone Africa/El_Aaiun uses an undefined rule Morocco The zone Africa/Casablanca uses an undefined rule Morocco The zone Indian/Mauritius uses an undefined rule +04/+05 The zone Pacific/Tongatapu uses an undefined rule Tonga The zone Pacific/Rarotonga uses an undefined rule Cook The zone Australia/Brisbane uses an undefined rule AQ The zone Australia/Perth uses an undefined rule AW The zone Australia/Darwin uses an undefined rule Aus The zone America/Montevideo uses an undefined rule Uruguay The zone America/Guayaquil uses an undefined rule Ecuador The zone America/Cuiaba uses an undefined rule Brazil The zone America/Campo_Grande uses an undefined rule Brazil The zone America/Sao_Paulo uses an undefined rule Brazil The zone America/Argentina/Tucuman uses an undefined rule Arg The zone America/Argentina/Cordoba uses an undefined rule Arg The zone America/Argentina/Buenos_Aires uses an undefined rule Arg I spot checked several of those – and there is no more daylight saving for those regions. Thus, the zone definition should contain a dash. I noticed some more inconsistencies specific to the “asia” file. The data separator is flexible. Everywhere, the tab is used as a separator. Here, the tab and the space are used interchangeably. Also in all the other files, the “Zone” is followed by a space and then the name. In this asia file, I noticed frequent use of tabs in between. Do you use space and tab alike? [cid:image001.png@01D674B8.E58BB0B0] Thank you, Juergen From: Juergen Naeckel Sent: Monday, August 17, 2020 3:02 PM To: tz@iana.org Subject: timezone DB distribution Hey there, First of all, I would like to thank you. I have to implement something in JavaScript that uses timezones. However, I am using an older JS version that does not have the flexibility like today’s JS. So I was looking for a repository holding all current timezones and rules for it, rather then me, checking time and again how which timezone is configured 😉 This really could help me. Reading through the files, it sometimes made me chuckle and I was actually surprised how fluent timezones are handled. Changes almost every year… I would like to recommend some improvements. I know you have pretty stable release by now. I am aware that changes probably to the structure might affect a lot of people/projects. However… First of all, a tar.gz is Linux specific. True, you could install additional Windows software. But, that might not go well with customers of mine. I think a ZIP would be acceptable for both worlds. Since I was interested in the repository, I downloaded the “Data only distribution”. I found six files containing the TZ information. And I found 27 files, containing other stuff. Well, there might be three or four files in a grey zone (calendars, backlist…). But I definitely do not consider MAKEFILE and .awk file as part of a “data only distribution”. Maybe move them to a separate folder in the GZ file? Finally, I got one more recommendation/question. I had read the readme file but it didn’t explain the data I saw in the files. It took me a while to understand the concept of the data structure. Some info of what to see in the file, and how to read it would help. And I think the first line of the ZONE definition contains some inconsistency (maybe I still didn’t understand it correctly). Below is a screenshot. See the first line for the zones? It looks mismatched with the New York. The RULE and the [UNTIL] are probably in the wrong column. Format is probably missing. [cid:image002.png@01D674B5.472618F0] Then I noticed that the open-end validity. For rules it is denoted as “max” and for zones it is just a <blank>. Could we get some consistency here? And finally here comes my question: In the rules, I see in the column several times denoted with a tailing “u” or “s”. I think I read on one occasion that the times are denoted in “standard time”. I do not recall anymore where that was. But regardless, 1. I don’t understand what that “denoted in standard time” would mean 2. I definitely have no clue would the tailing “u”: would imply. [cid:image003.png@01D674B5.472618F0] Can you shed some light on this? Thank you! Not only for an answer but also for researching and compiling this list. Juergen Juergen Naeckel PRINCIPAL ARCHITECT T 617 766 2381 | C 617 775 3874 naeckel@adobe.com<mailto:naeckel@adobe.com> [cid:image004.png@01D674B5.472618F0]
On Aug 17, 2020, at 2:07 PM, Juergen Naeckel via tz <tz@iana.org> wrote:
I tried to use the data provided in the timezone files. I ran some consistency checks. I think I found some inconsistencies.
Zone America/Barbados – has rule BARB, but none of the BARB rules is currently valid.
"Barb", not "BARB". I think # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Barb 1977 only - Jun 12 2:00 1:00 D Rule Barb 1977 1978 - Oct Sun>=1 2:00 0 S Rule Barb 1978 1980 - Apr Sun>=15 2:00 1:00 D Rule Barb 1979 only - Sep 30 2:00 0 S Rule Barb 1980 only - Sep 25 2:00 0 S means "the last transition between Daylight Saving Time and standard time was on 1980-09-25, and it switched to standard time; they've been on standard time ever since". Perhaps the documentation (currently, the zic man page) should make that a bit clearer. An alternative would, I think, be to have the Zone and continuation lines for Barbados be something such as Zone America/Barbados -3:58:29 - LMT 1924 # Bridgetown -3:58:29 - BMT 1932 # Bridgetown Mean Time -4:00 Barb A%sT 1980 -4:00 Barb AST or Zone America/Barbados -3:58:29 - LMT 1924 # Bridgetown -3:58:29 - BMT 1932 # Bridgetown Mean Time -4:00 - AST 1977 -4:00 Barb A%sT 1980 -4:00 - AST
Zone America/Costa_Rica – has rule CR, but none of the CR rules is currently valid.Zone America/El_Salvador – has rule BARB, but none of the rules is currently valid
Zone America/Guatemala – has rule Salv, but none of the rules is currently valid
Zone America/Tegucigalpa – has rule Hond, but none of the rules is currently valid
I think the same applies there.
The zone Africa/Johannesburg uses an undefined rule SA
The current version of the africa file in the Git repository has # South Africa # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule SA 1942 1943 - Sep Sun>=15 2:00 1:00 - Rule SA 1943 1944 - Mar Sun>=15 2:00 0 - # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Africa/Johannesburg 1:52:00 - LMT 1892 Feb 8 1:30 - SAST 1903 Mar 2:00 SA SAST which defines the SA rules directly above the Africa/Johannesburg zone.
The zone Africa/El_Aaiun uses an undefined rule Morocco
The zone Africa/Casablanca uses an undefined rule Morocco
In the current version, the Rule lines for Morocco are above the Zone entry for Africa/Casablanca.
The zone Indian/Mauritius uses an undefined rule +04/+05
In the current file, it has # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Mauritius 1982 only - Oct 10 0:00 1:00 - Rule Mauritius 1983 only - Mar 21 0:00 0 - Rule Mauritius 2008 only - Oct lastSun 2:00 1:00 - Rule Mauritius 2009 only - Mar lastSun 2:00 0 - # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Indian/Mauritius 3:50:00 - LMT 1907 # Port Louis 4:00 Mauritius +04/+05 The rule for Indian/Mauritius is Mauritus, the format used for the time zone string is "+04/+05", so dates look something like Wed Aug 19 07:22:27 +04 2020 (it would be +05 if DST were in effect).
The zone Pacific/Tongatapu uses an undefined rule Tonga
No, they're there, at least in the current Git version; the same applies to the other examples. Read the file in a text editor, not in Excel.
I spot checked several of those – and there is no more daylight saving for those regions. Thus, the zone definition should contain a dash.
They could have continuation lines with -, including the final continuation line, as per the above; it's not a requirement, however.
I noticed some more inconsistencies specific to the “asia” file. The data separator is flexible. Everywhere, the tab is used as a separator. Here, the tab and the space are used interchangeably. Also in all the other files, the “Zone” is followed by a space and then the name. In this asia file, I noticed frequent use of tabs in between. Do you use space and tab alike?
As noted, the file format does not require particular forms of white space.
Juergen, A few answers to some of your interpretation questions— On Tue, 18 Aug 2020 at 19:09, Juergen Naeckel via tz <tz@iana.org> wrote:
See the first line for the zones? It looks mismatched with the New York. The RULE and the [UNTIL] are probably in the wrong column.
The fields in Zone lines are delimited by whitespace, but not necessarily any amount or type of whitespace. In general, these files are meant to be viewed in a standard text editor with a tabstop of 8 spaces, rather than treated as a tab-separated values (TSV) document.
And finally here comes my question: In the rules, I see in the column several times denoted with a tailing “u” or “s”. I think I read on one occasion that the times are denoted in “standard time”. I do not recall anymore where that was. But regardless,
1. I don’t understand what that “denoted in standard time” would mean 2. I definitely have no clue would the tailing “u”: would imply.
I'll take the second one first, since it's easier: A trailing 'u' means the time-of-day is denoted in Universal Time, or UTC. So the October EU rule at the bottom of your screenshot, for example, takes effect at 01:00 UTC for all zones to which it applies: which might represent a 02:00-->01:00 transition in London but 04:00-->03:00 in Athens.
The 's' for standard time is a similar principle, but more subtle. Daylight saving is implemented by the presence of a non-zero SAVE value in Rule lines. This does not change the standard time itself, but rather adds (or in some cases, subtracts) an additional offset *to* that standard time. For example, standard time in America/New_York is UTC-5 hrs, but because there is currently 1 hour of DST in effect, the "total" calculated offset is UTC-4 hrs. Unlike how DST is observed in much of the US, which springs forward and falls back *from* 02:00 local "wall-clock" time, based on whatever offset was in effect immediately prior to the transition, some jurisdictions spring forward *from* a certain time-of-day and later fall backward *to* that same time. The 's' allows us to simplify how we write/read those rules: *Example: Transitions at 02:00s* Spring transition: *02:00 standard time* --> 03:00 daylight time Fall transition: 03:00 daylight time --> *02:00 standard time* *By contrast with transitions at 02:00 (without the 's', US model)* Spring transition: *02:00 standard time* --> 03:00 daylight time Fall transition: *02:00 daylight time* --> 01:00 standard time As for most of your other remarks, it is worth keeping in mind that the tzdata is truly meant to be a living historical document which is just as easy for humans to read, interpret, and understand as it is for computers to compile into TZif binary files or other formats. In most cases, there is a human legibility/understandability reason behind apparent inefficiencies in how the data is encoded; often because it better reflects the intent or effect of the laws that effectuated such changes. -- Tim Parenti
On Aug 17, 2020, at 12:01 PM, Juergen Naeckel via tz <tz@iana.org> wrote:
First of all, I would like to thank you. I have to implement something in JavaScript that uses timezones. However, I am using an older JS version that does not have the flexibility like today’s JS. So I was looking for a repository holding all current timezones and rules for it, rather then me, checking time and again how which timezone is configured 😉 This really could help me. Reading through the files, it sometimes made me chuckle and I was actually surprised how fluent timezones are handled. Changes almost every year… I would like to recommend some improvements. I know you have pretty stable release by now. I am aware that changes probably to the structure might affect a lot of people/projects. However… First of all, a tar.gz is Linux specific.
Or, rather, UN*X specific; Linux Torvalds was about 10 years old when tar was first broadly available (with V7 in 1979, I think), and gzip came out a little more than a year after somebody announced that they were "doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones", although it did support bash and gcc when that announcement was made. :-) But...
True, you could install additional Windows software. But, that might not go well with customers of mine. I think a ZIP would be acceptable for both worlds.
...offering both a tarball and a zipball might be a good idea (zip exists as a UN*X command, and ships with at least UN*Xes, but UN*X users may be less used to it).
Finally, I got one more recommendation/question. I had read the readme file but it didn’t explain the data I saw in the files.
Perhaps we should also 1) split the part of the zic man page that describes the file format into a separate man page and 2) provide formatted versions for people not on UN*X systems.
It took me a while to understand the concept of the data structure. Some info of what to see in the file, and how to read it would help. And I think the first line of the ZONE definition contains some inconsistency (maybe I still didn’t understand it correctly). Below is a screenshot. See the first line for the zones? It looks mismatched with the New York. The RULE and the [UNTIL] are probably in the wrong column. Format is probably missing.
As noted in Tim Parenti's reply, this isn't a strict tab-separated values file for consumption by spreadsheets, it's a file for 1) humans to read (so the columns are lined up visually) and 2) the zic program to read; there may be an arbitrary amount of white space between fields.
Then I noticed that the open-end validity. For rules it is denoted as “max” and for zones it is just a <blank>. Could we get some consistency here?
Consistency between "Zone" and "Rules" lines in the meaning of columns? They weren't designed to be the same - the file has four different types of lines; Rules lines, Zone lines, continuation lines, and "blank" lines, where "blank" lines are lines that have only 0 or more leading white space characters optionally followed by a comment. "Zone"/continuation lines and "Rules" lines serve different purposes and have a different syntax. Here's a formatted version of the section of the zic man page that describes the format of the files. Input lines are made up of fields. Fields are separated from one another by any number of white space characters. Leading and trailing white space on input lines is ignored. An unquoted sharp character (#) in the input introduces a comment which extends to the end of the line the sharp character appears on. White space characters and sharp characters may be enclosed in double quotes (") if they are to be used as part of a field. Any line that is blank (after comment stripping) is ignored. Non-blank lines are expected to be of one of three types: rule lines, zone lines, and link lines. Names (such as month names) must be in English and are case insensitive. Abbreviations, if used, must be unambiguous in context. A rule line has the form: Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S For example: Rule US 1967 1973 - Apr lastSun 2:00 1:00 D The fields that make up a rule line are: NAME Give the (arbitrary) name of the set of rules this rule is part of. FROM Give the first year in which the rule applies. Any inte- ger year can be supplied; the Gregorian calendar is assumed. The word minimum (or an abbreviation) means the minimum year representable as an integer. The word maximum (or an abbreviation) means the maximum year rep- resentable as an integer. Rules can describe times that are not representable as time values, with the unrepre- sentable times ignored; this allows rules to be portable among hosts with differing time value types. TO Give the final year in which the rule applies. In addi- tion to minimum and maximum (as above), the word only (or an abbreviation) may be used to repeat the value of the FROM field. TYPE Give the type of year in which the rule applies. If TYPE is - then the rule applies in all years between FROM and TO inclusive. If TYPE is something else, then zic exe- cutes the command yearistype year type to check the type of a year: an exit status of zero is taken to mean that the year is of the given type; an exit status of one is taken to mean that the year is not of the given type. IN Name the month in which the rule takes effect. Month names may be abbreviated. ON Give the day on which the rule takes effect. Recognized forms include: 5 the fifth of the month lastSun the last Sunday in the month lastMon the last Monday in the month Sun>=8 first Sunday on or after the eighth Sun<=25 last Sunday on or before the 25th Names of days of the week may be abbreviated or spelled out in full. Note that there must be no spaces within the ON field. AT Give the time of day at which the rule takes effect. Recognized forms include: 2 time in hours 2:00 time in hours and minutes 15:00 24-hour format time (for times after noon) 1:28:14 time in hours, minutes, and seconds where hour 0 is midnight at the start of the day, and hour 24 is midnight at the end of the day. Any of these forms may be followed by the letter `w' if the given time is local ``wall clock'' time, `s' if the given time is local ``standard'' time, or `u' (or `g' or `z') if the given time is universal time; in the absence of an indi- cator, wall clock time is assumed. SAVE Give the amount of time to be added to local standard time when the rule is in effect. This field has the same format as the AT field (although, of course, the `w' and `s' suffixes are not used). LETTER/S Give the ``variable part'' (for example, the ``S'' or ``D'' in ``EST'' or ``EDT'') of time zone abbreviations to be used when this rule is in effect. If this field is -, the variable part is null. A zone line has the form: Zone NAME GMTOFF RULES/SAVE FORMAT [UNTILYEAR [MONTH [DAY [TIME]]]] For example: Zone Australia/Adelaide 9:30 Aus CST 1971 Oct 31 2:00 The fields that make up a zone line are: NAME The name of the time zone. This is the name used in creating the time conversion information file for the zone. GMTOFF The amount of time to add to UTC to get standard time in this zone. This field has the same format as the AT and SAVE fields of rule lines; begin the field with a minus sign if time must be subtracted from UTC. RULES/SAVE The name of the rule(s) that apply in the time zone or, alter- nately, an amount of time to add to local standard time. If this field is - then standard time always applies in the time zone. FORMAT The format for time zone abbreviations in this time zone. The pair of characters %s is used to show where the ``variable part'' of the time zone abbreviation goes. Alternately, a slash (/) separates standard and daylight abbreviations. UNTILYEAR [MONTH [DAY [TIME]]] The time at which the UTC offset or the rule(s) change for a location. It is specified as a year, a month, a day, and a time of day. If this is specified, the time zone information is gen- erated from the given UTC offset and rule change until the time specified. The month, day, and time of day have the same format as the IN, ON, and AT fields of a rule; trailing fields can be omitted, and default to the earliest possible value for the miss- ing fields. The next line must be a ``continuation'' line; this has the same form as a zone line except that the string ``Zone'' and the name are omitted, as the continuation line will place information starting at the time specified as the until information in the previous line in the file used by the previous line. Continua- tion lines may contain until information, just as zone lines do, indicating that the next line is a further continuation. A link line has the form Link LINK-FROM LINK-TO For example: Link Europe/Istanbul Asia/Istanbul The LINK-FROM field should appear as the NAME field in some zone line; the LINK-TO field is used as an alternate name for that zone. Except for continuation lines, lines may appear in any order in the input. Lines in the file that describes leap seconds have the following form: Leap YEAR MONTH DAY HH:MM:SS CORR R/S For example: Leap 1974 Dec 31 23:59:60 + S The YEAR, MONTH, DAY, and HH:MM:SS fields tell when the leap second hap- pened. The CORR field should be ``+'' if a second was added or ``-'' if a second was skipped. The R/S field should be (an abbreviation of) ``Stationary'' if the leap second time given by the other fields should be interpreted as UTC or (an abbreviation of) ``Rolling'' if the leap second time given by the other fields should be interpreted as local wall clock time. EXTENDED EXAMPLE Here is an extended example of zic input, intended to illustrate many of its features. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Swiss 1940 only - Nov 2 0:00 1:00 S Rule Swiss 1940 only - Dec 31 0:00 0 - Rule Swiss 1941 1942 - May Sun>=1 2:00 1:00 S Rule Swiss 1941 1942 - Oct Sun>=1 0:00 0 Rule EU 1977 1980 - Apr Sun>=1 1:00u 1:00 S Rule EU 1977 only - Sep lastSun 1:00u 0 - Rule EU 1978 only - Oct 1 1:00u 0 - Rule EU 1979 1995 - Sep lastSun 1:00u 0 - Rule EU 1981 max - Mar lastSun 1:00u 1:00 S Rule EU 1996 max - Oct lastSun 1:00u 0 - # Zone NAME GMTOFF RULES FORMAT UNTIL Zone Europe/Zurich 0:34:08 - LMT 1848 Sep 12 0:29:44 - BMT 1894 Jun 1:00 Swiss CE%sT 1981 1:00 EU CE%sT Link Europe/Zurich Switzerland In this example, the zone is named Europe/Zurich but it has an alias as Switzerland. Zurich was 34 minutes and 8 seconds west of GMT until 1848-09-12 at 00:00, when the offset changed to 29 minutes and 44 sec- onds. After 1894-06-01 at 00:00 Swiss daylight saving rules (defined with lines beginning with "Rule Swiss") apply, and the GMT offset became one hour. From 1981 to the present, EU daylight saving rules have applied, and the UTC offset has remained at one hour. In 1940, daylight saving time applied from November 2 at 00:00 to Decem- ber 31 at 00:00. In 1941 and 1942, daylight saving time applied from the first Sunday in May at 02:00 to the first Sunday in October at 00:00. The pre-1981 EU daylight-saving rules have no effect here, but are included for completeness. Since 1981, daylight saving has begun on the last Sunday in March at 01:00 UTC. Until 1995 it ended the last Sunday in September at 01:00 UTC, but this changed to the last Sunday in October starting in 1996. For purposes of display, "LMT" and "BMT" were initially used, respec- tively. Since Swiss rules and later EU rules were applied, the display name for the timezone has been CET for standard time and CEST for day- light saving time. NOTES For areas with more than two types of local time, you may need to use local standard time in the AT field of the earliest transition time's rule to ensure that the earliest transition time recorded in the compiled file is correct. If, for a particular zone, a clock advance caused by the start of day- light saving coincides with and is equal to a clock retreat caused by a change in UTC offset, zic produces a single transition to daylight saving at the new UTC offset (without any change in wall clock time). To get separate transitions use multiple zone continuation lines specifying transition instants using universal time.
Hi. Just want to add that there are already several time zone libraries for JavaScript. Of course, you're welcome to create another, but if you were just looking for adding time zone support in an existing application you don't need to start from scratch. For modern browsers (and recent versions of Node.js), I'll recommend either Luxon (https://moment.github.io/luxon/) or date-fns-tz (https://github.com/marnusw/date-fns-tz). The latter is an add-on for date-fns (https://date-fns.org/). With either, you're relying on the tzdata that's bundled with the browser and exposed via the JavaScript Intl API. If you need to support older browsers, you can either use one of the previously mentioned libraries and also add the Intl Polyfill (https://github.com/formatjs/date-time-format-timezone), or you can use Moment-Timezone (https://momentjs.com/timezone/), which is an add-on for Moment.js (https://momentjs.com/). With either one, your app would carry some form of the tzdata with it. I'll also say, as a Microsoft employee, generally we are fine with .tar.gz. Windows 10 has a built-in tar command. I don't see any particular advantage to exposing a separate .zip. The files are meant for developers and platform maintainers anyway, not for direct consumption by end-users. They are indeed also meant for human readability, but personally I find the unofficial copy on GitHub (https://github.com/eggert/tz) much easier to browse for that, especially considering that you can generate permalinks to specific lines within specific tagged versions of the data. Cheers, Matt ________________________________ From: tz <tz-bounces@iana.org> on behalf of Guy Harris <gharris@sonic.net> Sent: Tuesday, August 18, 2020 8:04 PM To: Juergen Naeckel <naeckel@adobe.com> Cc: tz@iana.org <tz@iana.org> Subject: Re: [tz] timezone DB distribution On Aug 17, 2020, at 12:01 PM, Juergen Naeckel via tz <tz@iana.org> wrote:
First of all, I would like to thank you. I have to implement something in JavaScript that uses timezones. However, I am using an older JS version that does not have the flexibility like today’s JS. So I was looking for a repository holding all current timezones and rules for it, rather then me, checking time and again how which timezone is configured 😉 This really could help me. Reading through the files, it sometimes made me chuckle and I was actually surprised how fluent timezones are handled. Changes almost every year… I would like to recommend some improvements. I know you have pretty stable release by now. I am aware that changes probably to the structure might affect a lot of people/projects. However… First of all, a tar.gz is Linux specific.
Or, rather, UN*X specific; Linux Torvalds was about 10 years old when tar was first broadly available (with V7 in 1979, I think), and gzip came out a little more than a year after somebody announced that they were "doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones", although it did support bash and gcc when that announcement was made. :-) But...
True, you could install additional Windows software. But, that might not go well with customers of mine. I think a ZIP would be acceptable for both worlds.
...offering both a tarball and a zipball might be a good idea (zip exists as a UN*X command, and ships with at least UN*Xes, but UN*X users may be less used to it).
Finally, I got one more recommendation/question. I had read the readme file but it didn’t explain the data I saw in the files.
Perhaps we should also 1) split the part of the zic man page that describes the file format into a separate man page and 2) provide formatted versions for people not on UN*X systems.
It took me a while to understand the concept of the data structure. Some info of what to see in the file, and how to read it would help. And I think the first line of the ZONE definition contains some inconsistency (maybe I still didn’t understand it correctly). Below is a screenshot. See the first line for the zones? It looks mismatched with the New York. The RULE and the [UNTIL] are probably in the wrong column. Format is probably missing.
As noted in Tim Parenti's reply, this isn't a strict tab-separated values file for consumption by spreadsheets, it's a file for 1) humans to read (so the columns are lined up visually) and 2) the zic program to read; there may be an arbitrary amount of white space between fields.
Then I noticed that the open-end validity. For rules it is denoted as “max” and for zones it is just a <blank>. Could we get some consistency here?
Consistency between "Zone" and "Rules" lines in the meaning of columns? They weren't designed to be the same - the file has four different types of lines; Rules lines, Zone lines, continuation lines, and "blank" lines, where "blank" lines are lines that have only 0 or more leading white space characters optionally followed by a comment. "Zone"/continuation lines and "Rules" lines serve different purposes and have a different syntax. Here's a formatted version of the section of the zic man page that describes the format of the files. Input lines are made up of fields. Fields are separated from one another by any number of white space characters. Leading and trailing white space on input lines is ignored. An unquoted sharp character (#) in the input introduces a comment which extends to the end of the line the sharp character appears on. White space characters and sharp characters may be enclosed in double quotes (") if they are to be used as part of a field. Any line that is blank (after comment stripping) is ignored. Non-blank lines are expected to be of one of three types: rule lines, zone lines, and link lines. Names (such as month names) must be in English and are case insensitive. Abbreviations, if used, must be unambiguous in context. A rule line has the form: Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S For example: Rule US 1967 1973 - Apr lastSun 2:00 1:00 D The fields that make up a rule line are: NAME Give the (arbitrary) name of the set of rules this rule is part of. FROM Give the first year in which the rule applies. Any inte- ger year can be supplied; the Gregorian calendar is assumed. The word minimum (or an abbreviation) means the minimum year representable as an integer. The word maximum (or an abbreviation) means the maximum year rep- resentable as an integer. Rules can describe times that are not representable as time values, with the unrepre- sentable times ignored; this allows rules to be portable among hosts with differing time value types. TO Give the final year in which the rule applies. In addi- tion to minimum and maximum (as above), the word only (or an abbreviation) may be used to repeat the value of the FROM field. TYPE Give the type of year in which the rule applies. If TYPE is - then the rule applies in all years between FROM and TO inclusive. If TYPE is something else, then zic exe- cutes the command yearistype year type to check the type of a year: an exit status of zero is taken to mean that the year is of the given type; an exit status of one is taken to mean that the year is not of the given type. IN Name the month in which the rule takes effect. Month names may be abbreviated. ON Give the day on which the rule takes effect. Recognized forms include: 5 the fifth of the month lastSun the last Sunday in the month lastMon the last Monday in the month Sun>=8 first Sunday on or after the eighth Sun<=25 last Sunday on or before the 25th Names of days of the week may be abbreviated or spelled out in full. Note that there must be no spaces within the ON field. AT Give the time of day at which the rule takes effect. Recognized forms include: 2 time in hours 2:00 time in hours and minutes 15:00 24-hour format time (for times after noon) 1:28:14 time in hours, minutes, and seconds where hour 0 is midnight at the start of the day, and hour 24 is midnight at the end of the day. Any of these forms may be followed by the letter `w' if the given time is local ``wall clock'' time, `s' if the given time is local ``standard'' time, or `u' (or `g' or `z') if the given time is universal time; in the absence of an indi- cator, wall clock time is assumed. SAVE Give the amount of time to be added to local standard time when the rule is in effect. This field has the same format as the AT field (although, of course, the `w' and `s' suffixes are not used). LETTER/S Give the ``variable part'' (for example, the ``S'' or ``D'' in ``EST'' or ``EDT'') of time zone abbreviations to be used when this rule is in effect. If this field is -, the variable part is null. A zone line has the form: Zone NAME GMTOFF RULES/SAVE FORMAT [UNTILYEAR [MONTH [DAY [TIME]]]] For example: Zone Australia/Adelaide 9:30 Aus CST 1971 Oct 31 2:00 The fields that make up a zone line are: NAME The name of the time zone. This is the name used in creating the time conversion information file for the zone. GMTOFF The amount of time to add to UTC to get standard time in this zone. This field has the same format as the AT and SAVE fields of rule lines; begin the field with a minus sign if time must be subtracted from UTC. RULES/SAVE The name of the rule(s) that apply in the time zone or, alter- nately, an amount of time to add to local standard time. If this field is - then standard time always applies in the time zone. FORMAT The format for time zone abbreviations in this time zone. The pair of characters %s is used to show where the ``variable part'' of the time zone abbreviation goes. Alternately, a slash (/) separates standard and daylight abbreviations. UNTILYEAR [MONTH [DAY [TIME]]] The time at which the UTC offset or the rule(s) change for a location. It is specified as a year, a month, a day, and a time of day. If this is specified, the time zone information is gen- erated from the given UTC offset and rule change until the time specified. The month, day, and time of day have the same format as the IN, ON, and AT fields of a rule; trailing fields can be omitted, and default to the earliest possible value for the miss- ing fields. The next line must be a ``continuation'' line; this has the same form as a zone line except that the string ``Zone'' and the name are omitted, as the continuation line will place information starting at the time specified as the until information in the previous line in the file used by the previous line. Continua- tion lines may contain until information, just as zone lines do, indicating that the next line is a further continuation. A link line has the form Link LINK-FROM LINK-TO For example: Link Europe/Istanbul Asia/Istanbul The LINK-FROM field should appear as the NAME field in some zone line; the LINK-TO field is used as an alternate name for that zone. Except for continuation lines, lines may appear in any order in the input. Lines in the file that describes leap seconds have the following form: Leap YEAR MONTH DAY HH:MM:SS CORR R/S For example: Leap 1974 Dec 31 23:59:60 + S The YEAR, MONTH, DAY, and HH:MM:SS fields tell when the leap second hap- pened. The CORR field should be ``+'' if a second was added or ``-'' if a second was skipped. The R/S field should be (an abbreviation of) ``Stationary'' if the leap second time given by the other fields should be interpreted as UTC or (an abbreviation of) ``Rolling'' if the leap second time given by the other fields should be interpreted as local wall clock time. EXTENDED EXAMPLE Here is an extended example of zic input, intended to illustrate many of its features. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Swiss 1940 only - Nov 2 0:00 1:00 S Rule Swiss 1940 only - Dec 31 0:00 0 - Rule Swiss 1941 1942 - May Sun>=1 2:00 1:00 S Rule Swiss 1941 1942 - Oct Sun>=1 0:00 0 Rule EU 1977 1980 - Apr Sun>=1 1:00u 1:00 S Rule EU 1977 only - Sep lastSun 1:00u 0 - Rule EU 1978 only - Oct 1 1:00u 0 - Rule EU 1979 1995 - Sep lastSun 1:00u 0 - Rule EU 1981 max - Mar lastSun 1:00u 1:00 S Rule EU 1996 max - Oct lastSun 1:00u 0 - # Zone NAME GMTOFF RULES FORMAT UNTIL Zone Europe/Zurich 0:34:08 - LMT 1848 Sep 12 0:29:44 - BMT 1894 Jun 1:00 Swiss CE%sT 1981 1:00 EU CE%sT Link Europe/Zurich Switzerland In this example, the zone is named Europe/Zurich but it has an alias as Switzerland. Zurich was 34 minutes and 8 seconds west of GMT until 1848-09-12 at 00:00, when the offset changed to 29 minutes and 44 sec- onds. After 1894-06-01 at 00:00 Swiss daylight saving rules (defined with lines beginning with "Rule Swiss") apply, and the GMT offset became one hour. From 1981 to the present, EU daylight saving rules have applied, and the UTC offset has remained at one hour. In 1940, daylight saving time applied from November 2 at 00:00 to Decem- ber 31 at 00:00. In 1941 and 1942, daylight saving time applied from the first Sunday in May at 02:00 to the first Sunday in October at 00:00. The pre-1981 EU daylight-saving rules have no effect here, but are included for completeness. Since 1981, daylight saving has begun on the last Sunday in March at 01:00 UTC. Until 1995 it ended the last Sunday in September at 01:00 UTC, but this changed to the last Sunday in October starting in 1996. For purposes of display, "LMT" and "BMT" were initially used, respec- tively. Since Swiss rules and later EU rules were applied, the display name for the timezone has been CET for standard time and CEST for day- light saving time. NOTES For areas with more than two types of local time, you may need to use local standard time in the AT field of the earliest transition time's rule to ensure that the earliest transition time recorded in the compiled file is correct. If, for a particular zone, a clock advance caused by the start of day- light saving coincides with and is equal to a clock retreat caused by a change in UTC offset, zic produces a single transition to daylight saving at the new UTC offset (without any change in wall clock time). To get separate transitions use multiple zone continuation lines specifying transition instants using universal time.
On Aug 19, 2020, at 10:17 AM, Matt Johnson-Pint <mj1856@hotmail.com> wrote:
The files are meant for developers and platform maintainers anyway, not for direct consumption by end-users.
Hence my suggestion that whatever Juergen is developing not require that end users download the tz database separately; it should bundle the tzdb, and provide updates when the tzdb is updated.
On 8/19/20 13:49, Guy Harris wrote:
On Aug 19, 2020, at 10:17 AM, Matt Johnson-Pint <mj1856@hotmail.com> wrote:
The files are meant for developers and platform maintainers anyway, not for direct consumption by end-users. Hence my suggestion that whatever Juergen is developing not require that end users download the tz database separately; it should bundle the tzdb, and provide updates when the tzdb is updated. tzdist?
On 2020-08-19 15:16, Michael Douglass wrote:
On 8/19/20 13:49, Guy Harris wrote:
On Aug 19, 2020, at 10:17 AM, Matt Johnson-Pint wrote:
The files are meant for developers and platform maintainers anyway, not for direct consumption by end-users.
Hence my suggestion that whatever Juergen is developing not require that end users download the tz database separately; it should bundle the tzdb, and provide updates when the tzdb is updated. tzdist?
tzdist server implementations? Leave it to the distro or platform to do the job as quickly as any other downstream org. Org update policies may be a bigger delaying factor than tzdb, distro, or platform. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
Brian Inglis wrote:
On 2020-08-19 15:16, Michael Douglass wrote:
On 8/19/20 13:49, Guy Harris wrote:
On Aug 19, 2020, at 10:17 AM, Matt Johnson-Pint wrote:
The files are meant for developers and platform maintainers anyway, not for direct consumption by end-users.
Hence my suggestion that whatever Juergen is developing not require that end users download the tz database separately; it should bundle the tzdb, and provide updates when the tzdb is updated. tzdist?
I'd really appreciate if tzdist would be more adapted and used.
tzdist server implementations?
I think there is at least one implementation available. What I'm wondering is if there are client implementations that can update the local TZ rules on the fly so that systems that are running continuously automatically start using the updated rules once they have become available.
Leave it to the distro or platform to do the job as quickly as any other downstream org.
Org update policies may be a bigger delaying factor than tzdb, distro, or platform.
And what about the IoT stuff and othere embedded systems for which there is no distro that is maintained and updated regularly? Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On 8/20/20 03:14, Martin Burnicki via tz wrote:
I'd really appreciate if tzdist would be more adapted and used.
tzdist server implementations? I think there is at least one implementation available.
There's at least 3 - either up to date with the spec or close.
What I'm wondering is if there are client implementations that can update the local TZ rules on the fly so that systems that are running continuously automatically start using the updated rules once they have become available.
Leave it to the distro or platform to do the job as quickly as any other downstream org.
Org update policies may be a bigger delaying factor than tzdb, distro, or platform.
Certainly some large organizations are unwilling (currently) to change their update policies - treating tz data as system code or being very slow with their updates. If you want truly up to date tz info you often have to fetch it yourself - which is where tzdist could be useful.
And what about the IoT stuff and othere embedded systems for which there is no distro that is maintained and updated regularly?
Martin
On 2020-08-20 11:34, Michael Douglass wrote:
On 8/20/20 03:14, Martin Burnicki via tz wrote:
I'd really appreciate if tzdist would be more adapted and used.
tzdist server implementations?
I think there is at least one implementation available.
There's at least 3 - either up to date with the spec or close.
I could find nothing of use - care to share the source repos, servers, or sites?
What I'm wondering is if there are client implementations that can update the local TZ rules on the fly so that systems that are running continuously automatically start using the updated rules once they have become available.
Leave it to the distro or platform to do the job as quickly as any other downstream org.
Org update policies may be a bigger delaying factor than tzdb, distro, or platform.
Certainly some large organizations are unwilling (currently) to change their update policies - treating tz data as system code or being very slow with their updates.
If you want truly up to date tz info you often have to fetch it yourself - which is where tzdist could be useful.
And what about the IoT stuff and other embedded systems for which there is no distro that is maintained and updated regularly?
They often have bigger issues with space for decoding, data storage, and use; one suggestion was a stream compressed list of file base names and POSIX strings from the last line of the files e.g. London GMT0BST,M3.5.0/1,M10.5.0\n... also could reduce the locations to one "airport" code per rule as in watches (extract from Casio manual): City UTC Code City Offset Other major cities in same time zone PPG Pago Pago –11.0 HNL Honolulu –10.0 Papeete ANC Anchorage –09.0 Nome YVR Vancouver –08.0 San Francisco, Las Vegas, LAX Los Angeles Seattle/Tacoma, Dawson City, Tijuana YEA Edmonton –07.0 El Paso, Culiacan DEN Denver MEX Mexico City –06.0 Houston, Dallas/Fort Worth, New Orleans YWG Winnipeg CHI Chicago MIA Miami –05.0 Montreal, Detroit, Boston, YTO Toronto Panama City, Havana, Lima, Bogota NYC New York CCS Caracas –04.0 La Paz, Santiago, Port Of Spain YHZ Halifax YYT St. Johns –03.5 RIO Rio De Janeiro –03.0 Sao Paulo, Buenos Aires, Brasilia, Montevideo RAI Praia –01.0 LIS Lisbon +00.0 Dublin, Casablanca, Dakar, Abidjan LON London BCN Barcelona +01.0 Amsterdam, Algiers, Hamburg, Frankfurt, Vienna MAD Madrid PAR Paris MIL Milan ROM Rome BER Berlin STO Stockholm ATH Athens +02.0 Helsinki, Istanbul, Beirut, Damascus, CAI Cairo Cape Town JRS Jerusalem MOW Moscow +03.0 Kuwait, Riyadh, Aden, Addis Ababa, Nairobi JED Jeddah THR Tehran +03.5 Shiraz DXB Dubai +04.0 Abu Dhabi, Muscat KBL Kabul +04.5 KHI Karachi +05.0 Male DEL Delhi +05.5 Mumbai, Kolkata DAC Dhaka +06.0 Colombo RGN Yangon +06.5 BKK Bangkok +07.0 Jakarta, Phnom Penh, Hanoi, Vientiane HKG Hong Kong +08.0 Singapore, Kuala Lumpur, Beijing, Taipei, Manila, Perth, Ulaanbaatar SEL Seoul +09.0 Pyongyang TYO Tokyo ADL Adelaide +09.5 Darwin GUM Guam +10.0 Melbourne, Rabaul SYD Sydney NOU Noumea +11.0 Port Vila WLG Wellington +12.0 Christchurch, Nadi, Nauru Island possibly squoze to Radix 50/Mod 40 (recently revived) or 5 bit Baudot code: https://hackaday.com/2016/11/22/squoze-your-data/ https://hackaday.com/2015/09/27/demonstrating-baudot-code/ -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
On 8/20/20 12:33 PM, Brian Inglis wrote:
They often have bigger issues with space for decoding, data storage, and use; one suggestion was a stream compressed list of file base names and POSIX strings from the last line of the files e.g.
The main argument for POSIX strings is simplicity rather than saving storage or network capacity or even CPU time. Currently all the tzdb data can be compressed to 22,418 bytes, via 'lzip -9 tzdata.zi'. Although limiting tzdata to (compressed) names and POSIX strings would shrink that considerably, I doubt whether the data shrinkage is worth it, except perhaps for embedded applications where all timestamps are future timestamps.
On 2020-08-20 14:37, Paul Eggert wrote:
On 8/20/20 12:33 PM, Brian Inglis wrote:
They often have bigger issues with space for decoding, data storage, and use; one suggestion was a stream compressed list of file base names and POSIX strings from the last line of the files e.g.
The main argument for POSIX strings is simplicity rather than saving storage or network capacity or even CPU time. Currently all the tzdb data can be compressed to 22,418 bytes, via 'lzip -9 tzdata.zi'. Although limiting tzdata to (compressed) names and POSIX strings would shrink that considerably, I doubt whether the data shrinkage is worth it, except perhaps for embedded applications where all timestamps are future timestamps.
Agreed - the issues are not on IoT dev SoC boards with GB of RAM and flash, running minimal BSD or Linux distros, but the deployed SoCs may have only MB or even KB of ROM, RAM, and perhaps no flash. The code space and memory required for modern decompressors may be over the available memory budget on the chip and perhaps over the available time budget for the deployed processor speed. The simple reference lzip decompressor lzd requires 5MB virtual on a 32 bit system. Editing approaches such as using tzdata.zi, POSIX TZ strings, airport codes for locations, and eliminating all but a single location with identical current rule sets per offset, probably reduce size more and allow lighter weight code for limited memory systems. For comparison, I took the current continent data files only, concatenated, tarred, zipped, 7zed them to produce the tz.* files, also picked the POSIX TZ strings from the last lines of the equivalent zoneinfo files, kept only the basename of the path, and manually eliminated truly redundant duplicated names to get tz-posix.log, then compressed tz.tar, tz.txt, tzdata.zi, and tz-posix.log, using the available compressors, all using the highest -9 compression where available, including zip with bzip2, to get the following file and archive sizes: 750K tz.tar 741K tz.txt 329K tz.tar.Z 328K tz.txt.Z 251K tz.tar.gz 250K tz.txt.gz 225K tz.tar.zst 224K tz.txt.zst 219K tz.zip 202K tz.tar.7z 202K tz.tar.xz 202K tz.7z 202K tz.txt.7z 202K tz.txt.xz 202K tz.tar.lz 201K tz.txt.lz 192K tz.tar.zip 192K tz.tar.bz2 192K tz.txt.zip 192K tz.txt.bz2 109K tzdata.zi 39K tzdata.zi.Z 27K tzdata.zi.gz 26K tzdata.zi.zst 22K tzdata.zi.7z 22K tzdata.zi.xz 22K tzdata.zi.lz 22K tzdata.zi.zip 22K tzdata.zi.bz2 12K tz-posix.log 5.4K tz-posix.log.Z 3.8K tz-posix.log.gz 3.7K tz-posix.log.zst 3.6K tz-posix.log.zip 3.6K tz-posix.log.7z 3.5K tz-posix.log.xz 3.5K tz-posix.log.lz 3.5K tz-posix.log.bz2 -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
On 22/08/2020 20:29, Brian Inglis wrote:
Agreed - the issues are not on IoT dev SoC boards with GB of RAM and flash, running minimal BSD or Linux distros, but the deployed SoCs may have only MB or even KB of ROM, RAM, and perhaps no flash.
Many slave devices do not rely on having a power consuming clock actually on board and instead access a master time source on the system, so the need for a full calendar system is avoided, but instead the time service needs to handle DST changes and this is where tzdist provides a documented standard to provide that area of the service. -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk
Hi Lester and others, On 23.08.20 10:24, Lester Caine wrote:
Many slave devices do not rely on having a power consuming clock actually on board and instead access a master time source on the system, so the need for a full calendar system is avoided, but instead the time service needs to handle DST changes and this is where tzdist provides a documented standard to provide that area of the service.
As this discussion has demonstrated IoT is so widely varied that it is difficult to characterize a single set of requirements. There are a great many environments: 1. Consumer with an Internet connection, in which case it can use tzdist or similar, or it will have sufficient space to store the tz database, which itself was designed for efficiency. 2. BLE/BT/Zigbee device or similar with nothing. Here either it slaves time or doesn't bother at all. There are power scavenging switches that fall into this category, and certain classes of sensors like cement dryness ones that are intended to only work for 4-6 weeks on low power. 3. Full powered PLCs that do not have Internet access. These will take software updates from time to time, and will vary how much they care, depending on auditing requirements, but likely will operate in GMT for those due to synchronization issues. 4. Low powered long-lived devices. A good example of this would be a box car sensor on the railroad that has to go five years without scavenging (e.g., battery), which will periodically chirp a message. It may need synchronization with neighboring cars, but won't use a fixed time to do it because it won't have an RTC. A great many devices will only be updated very rarely. They do not have Internet access and will be in inconvenient places, like the ground in an oil field in Alaska. Some will have downtime windows, like devices used in battle conditions. Some devices won't be put into service for years, and when they are, they'll be expected to function properly. In all of these cases, I suspect that either TZ can accommodate them with what's there today, or there is no standard change that will accommodate them at all. Eliot
On 23/08/2020 10:11, Eliot Lear wrote:
Hi Lester and others,
On 23.08.20 10:24, Lester Caine wrote:
Many slave devices do not rely on having a power consuming clock actually on board and instead access a master time source on the system, so the need for a full calendar system is avoided, but instead the time service needs to handle DST changes and this is where tzdist provides a documented standard to provide that area of the service.
As this discussion has demonstrated IoT is so widely varied that it is difficult to characterize a single set of requirements. There are a great many environments:
1. Consumer with an Internet connection, in which case it can use tzdist or similar, or it will have sufficient space to store the tz database, which itself was designed for efficiency. 2. BLE/BT/Zigbee device or similar with nothing. Here either it slaves time or doesn't bother at all. There are power scavenging switches that fall into this category, and certain classes of sensors like cement dryness ones that are intended to only work for 4-6 weeks on low power. 3. Full powered PLCs that do not have Internet access. These will take software updates from time to time, and will vary how much they care, depending on auditing requirements, but likely will operate in GMT for those due to synchronization issues. 4. Low powered long-lived devices. A good example of this would be a box car sensor on the railroad that has to go five years without scavenging (e.g., battery), which will periodically chirp a message. It may need synchronization with neighboring cars, but won't use a fixed time to do it because it won't have an RTC.
A great many devices will only be updated very rarely. They do not have Internet access and will be in inconvenient places, like the ground in an oil field in Alaska. Some will have downtime windows, like devices used in battle conditions. Some devices won't be put into service for years, and when they are, they'll be expected to function properly.
In all of these cases, I suspect that either TZ can accommodate them with what's there today, or there is no standard change that will accommodate them at all.
I should perhaps have elaborated a little. Certainly the devices I was coding over 30 years ago were so small that the longest time frame was 7 days on central heating controllers which were indeed GMT time only. There was no discussion on handling DST other than changing the clock twice a year. Today those elements are generally LOCALLY networked such as boiler control, thermostatic valves and even lighting control. The distributed system does not need internet access, but like most 'smart watches' these days, it can't even tell the time without it's central smart element. The key here is that these systems do not need access to the full gamete of TZ data, simply a single rule set, and even then filtered by perhaps the next couple of years. Something that tzdist serves perfectly and even flags when a forthcoming DST event may be changed from what was originally published. Saving a few bytes of space from a full TZ distribution is perhaps not the best use of time ... getting a fully functional tzdist is what is missing today? The 'distribution' mechanism, rather than the 'DB' ... -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk
On 8/20/20 15:33, Brian Inglis wrote:
On 2020-08-20 11:34, Michael Douglass wrote:
On 8/20/20 03:14, Martin Burnicki via tz wrote:
I'd really appreciate if tzdist would be more adapted and used.
tzdist server implementations? I think there is at least one implementation available. There's at least 3 - either up to date with the spec or close. I could find nothing of use - care to share the source repos, servers, or sites?
Sorry for the slow response - there's a new page at https://devguide.calconnect.org/Time-Zones/TZDS/ which is intended to list these servers.
On 2020-09-06 21:32, Michael Douglass wrote:
On 8/20/20 15:33, Brian Inglis wrote:
On 2020-08-20 11:34, Michael Douglass wrote:
On 8/20/20 03:14, Martin Burnicki via tz wrote:
I'd really appreciate if tzdist would be more adapted and used.
tzdist server implementations? I think there is at least one implementation available. There's at least 3 - either up to date with the spec or close. I could find nothing of use - care to share the source repos, servers, or sites?
Sorry for the slow response - there's a new page at https://devguide.calconnect.org/Time-Zones/TZDS/ which is intended to list these servers.
If you follow those links and dig into those servers, they appear to be mail server calendar addins, which use vzic to convert tzdata source into VTIMEZONEs, for updating and caching calendar zones, not providing any kind of service or distribution, except to their own mail server calendar clients. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
On 9/7/20 1:23 PM, Brian Inglis wrote:
If you follow those links and dig into those servers, they appear to be mail server calendar addins, which use vzic to convert tzdata source into VTIMEZONEs, for updating and caching calendar zones, not providing any kind of service or distribution, except to their own mail server calendar clients.
Thanks for following those links, which I didn't bother to do. If they don't support the TZDIST protocol then I suppose I should revert the recently-proposed change to tz-links.html[1] which says they do. [1] https://github.com/eggert/tz/commit/cb2d288ae0bb3aa5fb7cc94480ea955ff76bd183
A reasonable criterion for inclusion should probably be whether the service makes the protocol accessible for arbitrary consumption, whether openly or by authenticated subscription. The phrase "supports TZDIST" can of course mean several different things, but while there are benefits to using the protocol internally to a product, I don't think this fulfills the expectation that it would tend to evoke here. From the perspective of someone reading tz-link.html, it's much more important to answer "where are some public tzdist servers I can point my project to?" rather than "what's something that happens to speak tzdist to its own clients?" (The latter, frankly, is of little relevance to consumers of the tz project data.) -- Tim Parenti On Mon, 7 Sep 2020 at 17:24, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 9/7/20 1:23 PM, Brian Inglis wrote:
If you follow those links and dig into those servers, they appear to be mail server calendar addins, which use vzic to convert tzdata source into VTIMEZONEs, for updating and caching calendar zones, not providing any kind of service or distribution, except to their own mail server calendar clients.
Thanks for following those links, which I didn't bother to do. If they don't support the TZDIST protocol then I suppose I should revert the recently-proposed change to tz-links.html[1] which says they do.
[1] https://github.com/eggert/tz/commit/cb2d288ae0bb3aa5fb7cc94480ea955ff76bd183
On 9/7/20 19:43, Tim Parenti wrote:
A reasonable criterion for inclusion should probably be whether the service makes the protocol accessible for arbitrary consumption, whether openly or by authenticated subscription.
The phrase "supports TZDIST" can of course mean several different things, but while there are benefits to using the protocol internally to a product, I don't think this fulfills the expectation that it would tend to evoke here. From the perspective of someone reading tz-link.html, it's much more important to answer "where are some public tzdist servers I can point my project to?" rather than "what's something that happens to speak tzdist to its own clients?" (The latter, frankly, is of little relevance to consumers of the tz project data.)
We implemented (and use) those servers to provide a starting point. Having a service requires some infrastructure maintained by some body or consortium. I believe Ken's server fully supports tzdist (and beyond). Mine may be a little out of date but supports pretty much the latest. However, neither of us can provide the infrastructure - that's for somebody such as IANA
-- Tim Parenti
On Mon, 7 Sep 2020 at 17:24, Paul Eggert <eggert@cs.ucla.edu <mailto:eggert@cs.ucla.edu>> wrote:
On 9/7/20 1:23 PM, Brian Inglis wrote: > If you follow those links and dig into those servers, they appear to be mail > server calendar addins, which use vzic to convert tzdata source into VTIMEZONEs, > for updating and caching calendar zones, not providing any kind of service or > distribution, except to their own mail server calendar clients.
Thanks for following those links, which I didn't bother to do. If they don't support the TZDIST protocol then I suppose I should revert the recently-proposed change to tz-links.html[1] which says they do.
[1] https://github.com/eggert/tz/commit/cb2d288ae0bb3aa5fb7cc94480ea955ff76bd183
On 9/7/20 11:06 PM, Michael Douglass wrote:
On 9/7/20 19:43, Tim Parenti wrote:
A reasonable criterion for inclusion should probably be whether the service makes the protocol accessible for arbitrary consumption, whether openly or by authenticated subscription.
The phrase "supports TZDIST" can of course mean several different things, but while there are benefits to using the protocol internally to a product, I don't think this fulfills the expectation that it would tend to evoke here. From the perspective of someone reading tz-link.html, it's much more important to answer "where are some public tzdist servers I can point my project to?" rather than "what's something that happens to speak tzdist to its own clients?" (The latter, frankly, is of little relevance to consumers of the tz project data.)
We implemented (and use) those servers to provide a starting point. Having a service requires some infrastructure maintained by some body or consortium. I believe Ken's server fully supports tzdist (and beyond). Mine may be a little out of date but supports pretty much the latest.
The tzdist module in Cyrus should be completely up to date with RFC 7808 and will return RFC 8536-compliant TZif data when requested. It can also spit out zdump formatted data, which I used for debugging. Making this a stand-alone service would take a lot of work since it uses the built-in httpd server and shares a lot of I/O handling APIs with imapd, etc. -- Kenneth Murchison Senior Software Developer Fastmail US LLC
On 9/7/20 17:24, Paul Eggert wrote:
On 9/7/20 1:23 PM, Brian Inglis wrote:
If you follow those links and dig into those servers, they appear to be mail server calendar addins, which use vzic to convert tzdata source into VTIMEZONEs, for updating and caching calendar zones, not providing any kind of service or distribution, except to their own mail server calendar clients.
Thanks for following those links, which I didn't bother to do. If they don't support the TZDIST protocol then I suppose I should revert the recently-proposed change to tz-links.html[1] which says they do.
No - neither bedwork nor Darwin have any mail element - they are calendar and contacts servers. Both bedework (which I'm responsible for) and Cyrus (for which Ken is responsible) support TZdist. There is code in both to convert tzdata source - mine is partially working - Ken's is in much better shape. The reason VTIMEZONE was the only supported data format is it was the only one defined at the time. That's why Ken started the TZif definition so that TZDIST could deliver the data used by OSs for example. TZDIST is not data format specific. It's just that at this stage there aren't may defined formats. I can't speak for Cyrus but the tzdist server in bedework is a separate project in github. I can add a direct link
[1] https://github.com/eggert/tz/commit/cb2d288ae0bb3aa5fb7cc94480ea955ff76bd183
On 9/7/20 22:56, Michael Douglass wrote:
On 9/7/20 17:24, Paul Eggert wrote:
On 9/7/20 1:23 PM, Brian Inglis wrote:
If you follow those links and dig into those servers, they appear to be mail server calendar addins, which use vzic to convert tzdata source into VTIMEZONEs, for updating and caching calendar zones, not providing any kind of service or distribution, except to their own mail server calendar clients.
Thanks for following those links, which I didn't bother to do. If they don't support the TZDIST protocol then I suppose I should revert the recently-proposed change to tz-links.html[1] which says they do.
No - neither bedwork nor Darwin have any mail element - they are calendar and contacts servers. Both bedework (which I'm responsible for) and Cyrus (for which Ken is responsible) support TZdist.
There is code in both to convert tzdata source - mine is partially working - Ken's is in much better shape.
The reason VTIMEZONE was the only supported data format is it was the only one defined at the time. That's why Ken started the TZif definition so that TZDIST could deliver the data used by OSs for example.
TZDIST is not data format specific. It's just that at this stage there aren't may defined formats.
I can't speak for Cyrus but the tzdist server in bedework is a separate project in github. I can add a direct link
And I just realized it is already a direct link.
[1] https://github.com/eggert/tz/commit/cb2d288ae0bb3aa5fb7cc94480ea955ff76bd183
On 2020-09-07 20:59, Michael Douglass wrote:
On 9/7/20 22:56, Michael Douglass wrote:
On 9/7/20 17:24, Paul Eggert wrote:
On 9/7/20 1:23 PM, Brian Inglis wrote:
If you follow those links and dig into those servers, they appear to be mail server calendar addins, which use vzic to convert tzdata source into VTIMEZONEs, for updating and caching calendar zones, not providing any kind of service or distribution, except to their own mail server calendar clients.
Thanks for following those links, which I didn't bother to do. If they don't support the TZDIST protocol then I suppose I should revert the recently-proposed change to tz-links.html[1] which says they do.
No - neither bedwork nor Darwin have any mail element - they are calendar and contacts servers. Both bedework (which I'm responsible for) and Cyrus (for which Ken is responsible) support TZdist.
There is code in both to convert tzdata source - mine is partially working - Ken's is in much better shape.
The reason VTIMEZONE was the only supported data format is it was the only one defined at the time. That's why Ken started the TZif definition so that TZDIST could deliver the data used by OSs for example.
TZDIST is not data format specific. It's just that at this stage there aren't may defined formats.
I can't speak for Cyrus but the tzdist server in bedework is a separate project in github. I can add a direct link
And I just realized it is already a direct link.
But those implementations do not obviously appear to be able to run as standalone services, only as modules within their host mail/calendar server, responding to internal requests, not any documented external interface, and only support current timezones, as would running vzic statically against tzdata sources to produce files, not any history or delta updates e.g. show me what changed in zone a/b since version 2019c, nor respond to other servers to provide global updates, which would be the expectation of anyone on this list wanting to access or run what we would expect from a tzdist server. Blind replacement of a previous version with the current version does not really help anyone understand what changes in their schedule, other than the previous event disappears to be replaced by a new event with some common attributes, and requires all events be re-interpreted against whatever is updated or currently stored for that time zone data, whenever any process wants to determine which events are pending for some future period. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
On 9/8/20 01:18, Brian Inglis wrote:
On 2020-09-07 20:59, Michael Douglass wrote:
On 9/7/20 22:56, Michael Douglass wrote:
On 9/7/20 17:24, Paul Eggert wrote:
On 9/7/20 1:23 PM, Brian Inglis wrote:
If you follow those links and dig into those servers, they appear to be mail server calendar addins, which use vzic to convert tzdata source into VTIMEZONEs, for updating and caching calendar zones, not providing any kind of service or distribution, except to their own mail server calendar clients. Thanks for following those links, which I didn't bother to do. If they don't support the TZDIST protocol then I suppose I should revert the recently-proposed change to tz-links.html[1] which says they do. No - neither bedwork nor Darwin have any mail element - they are calendar and contacts servers. Both bedework (which I'm responsible for) and Cyrus (for which Ken is responsible) support TZdist.
There is code in both to convert tzdata source - mine is partially working - Ken's is in much better shape.
The reason VTIMEZONE was the only supported data format is it was the only one defined at the time. That's why Ken started the TZif definition so that TZDIST could deliver the data used by OSs for example.
TZDIST is not data format specific. It's just that at this stage there aren't may defined formats.
I can't speak for Cyrus but the tzdist server in bedework is a separate project in github. I can add a direct link And I just realized it is already a direct link. But those implementations do not obviously appear to be able to run as standalone services, only as modules within their host mail/calendar server, responding to internal requests, not any documented external interface,
Not true. Bedework can exist as a completely separate module - in fact is built with that assumption. While other may be built as part of a larger project they can still handle tzdist queries as laid out in the standard. The bedework tzdist server can run as a primary server delivering data from files or as a secondary server updating from another tzdist server. Bedework calendar server uses no internal requests to fetch timezones, it uses tzdist so it could fetch from some other remote server if one were available.
and only support current timezones, as would running vzic statically against tzdata sources to produce files, not any history or delta updates e.g. show me what changed in zone a/b since version 2019c, nor respond to other servers to provide global updates, which would be the expectation of anyone on this list wanting to access or run what we would expect from a tzdist server. Expectations differ.
Blind replacement of a previous version with the current version does not really help anyone understand what changes in their schedule, other than the previous event disappears to be replaced by a new event with some common attributes, and requires all events be re-interpreted against whatever is updated or currently stored for that time zone data, whenever any process wants to determine which events are pending for some future period.
Blind replacements are what we have currently. If an application is using OS or runtime system timezones they can change without notice at any time - whenever somebody decides to patch the underlying system. As a calendar implementer, deployer and maintainer I understand those specific problems. In fact to the organizer the event often looks unchanged - what might have changed is the UTC time that is equivalent to the local time. It's still the same event - has the same UID. And yes - we should reschedule to give all parties an opportunity to re-evaluate Tzdist was designed to allow consumers to determine what timezones had changed since they last asked. For a calendar system that at least allows us to limit our search of possibly impacted data. It would be nice if we had information on what changed and we can possibly derive that but that can be a later addition. But possible consumers of tzdist go beyond large scale calendar systems. When we started discussions about tzdist many years ago the phone vendors of the time were very enthusiastic. They could only store a few timezones and would like a standardized service that allowed them to fetch individual timezones. While phones have got more powerful I'm guessing that small devices are in the same position. They don't care much what changed but they do need to know that the timezone they use has changed. I quite understand that tzdist only solves part of the problem but it's a pretty widespread part and dealing with that in a standardized manner seems liek a good start.
On 8/19/20 10:17 AM, Matt Johnson-Pint wrote:
If you need to support older browsers, you can either use one of the previously mentioned libraries and also add the Intl Polyfill (https://github.com/formatjs/date-time-format-timezone), or you can use Moment-Timezone (https://momentjs.com/timezone/), which is an add-on for Moment.js (https://momentjs.com/). With either one, your app would carry some form of the tzdata with it.
Thanks for mentioning that. Although tz-link.html already mentioned Moment-Timezone, the timeZone option of JavaScript's Intl.DateTimeFormat is also worth mentioning as it can be a string like "America/Los_Angeles". I added the attached proposed patch to the development sources. It seems that pretty much every JavaScript runtime except Internet Explorer supports tz names in the timeZone option nowadays, though older versions of runtimes may lack this support. See: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Obj...
On Aug 17, 2020, at 12:01 PM, Juergen Naeckel via tz <tz@iana.org> wrote:
First of all, I would like to thank you. I have to implement something in JavaScript that uses timezones. However, I am using an older JS version that does not have the flexibility like today’s JS. So I was looking for a repository holding all current timezones and rules for it, rather then me, checking time and again how which timezone is configured 😉 This really could help me. Reading through the files, it sometimes made me chuckle and I was actually surprised how fluent timezones are handled. Changes almost every year… I would like to recommend some improvements. I know you have pretty stable release by now. I am aware that changes probably to the structure might affect a lot of people/projects. However… First of all, a tar.gz is Linux specific.
Or, rather, UN*X specific; Linux Torvalds was about 10 years old when tar was first broadly available (with V7 in 1979, I think), and gzip came out a little more than a year after somebody announced that they were "doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones", although it did support bash and gcc when that announcement was made. :-) But...
True, you could install additional Windows software. But, that might not go well with customers of mine. I think a ZIP would be acceptable for both worlds.
...offering both a tarball and a zipball might be a good idea (zip exists as a UN*X command, and ships with at least UN*Xes, but UN*X users may be less used to it).
Finally, I got one more recommendation/question. I had read the readme file but it didn’t explain the data I saw in the files.
Perhaps we should also 1) split the part of the zic man page that describes the file format into a separate man page and 2) provide formatted versions for people not on UN*X systems.
It took me a while to understand the concept of the data structure. Some info of what to see in the file, and how to read it would help. And I think the first line of the ZONE definition contains some inconsistency (maybe I still didn’t understand it correctly). Below is a screenshot. See the first line for the zones? It looks mismatched with the New York. The RULE and the [UNTIL] are probably in the wrong column. Format is probably missing.
As noted in Tim Parenti's reply, this isn't a strict tab-separated values file for consumption by spreadsheets, it's a file for 1) humans to read (so the columns are lined up visually) and 2) the zic program to read; there may be an arbitrary amount of white space between fields.
Then I noticed that the open-end validity. For rules it is denoted as “max” and for zones it is just a <blank>. Could we get some consistency here?
Consistency between "Zone" and "Rules" lines in the meaning of columns? They weren't designed to be the same - the file has four different types of lines; Rules lines, Zone lines, continuation lines, and "blank" lines, where "blank" lines are lines that have only 0 or more leading white space characters optionally followed by a comment. "Zone"/continuation lines and "Rules" lines serve different purposes and have a different syntax. Here's a formatted version of the section of the zic man page that describes the format of the files. Input lines are made up of fields. Fields are separated from one another by any number of white space characters. Leading and trailing white space on input lines is ignored. An unquoted sharp character (#) in the input introduces a comment which extends to the end of the line the sharp character appears on. White space characters and sharp characters may be enclosed in double quotes (") if they are to be used as part of a field. Any line that is blank (after comment stripping) is ignored. Non-blank lines are expected to be of one of three types: rule lines, zone lines, and link lines. Names (such as month names) must be in English and are case insensitive. Abbreviations, if used, must be unambiguous in context. A rule line has the form: Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S For example: Rule US 1967 1973 - Apr lastSun 2:00 1:00 D The fields that make up a rule line are: NAME Give the (arbitrary) name of the set of rules this rule is part of. FROM Give the first year in which the rule applies. Any inte- ger year can be supplied; the Gregorian calendar is assumed. The word minimum (or an abbreviation) means the minimum year representable as an integer. The word maximum (or an abbreviation) means the maximum year rep- resentable as an integer. Rules can describe times that are not representable as time values, with the unrepre- sentable times ignored; this allows rules to be portable among hosts with differing time value types. TO Give the final year in which the rule applies. In addi- tion to minimum and maximum (as above), the word only (or an abbreviation) may be used to repeat the value of the FROM field. TYPE Give the type of year in which the rule applies. If TYPE is - then the rule applies in all years between FROM and TO inclusive. If TYPE is something else, then zic exe- cutes the command yearistype year type to check the type of a year: an exit status of zero is taken to mean that the year is of the given type; an exit status of one is taken to mean that the year is not of the given type. IN Name the month in which the rule takes effect. Month names may be abbreviated. ON Give the day on which the rule takes effect. Recognized forms include: 5 the fifth of the month lastSun the last Sunday in the month lastMon the last Monday in the month Sun>=8 first Sunday on or after the eighth Sun<=25 last Sunday on or before the 25th Names of days of the week may be abbreviated or spelled out in full. Note that there must be no spaces within the ON field. AT Give the time of day at which the rule takes effect. Recognized forms include: 2 time in hours 2:00 time in hours and minutes 15:00 24-hour format time (for times after noon) 1:28:14 time in hours, minutes, and seconds where hour 0 is midnight at the start of the day, and hour 24 is midnight at the end of the day. Any of these forms may be followed by the letter `w' if the given time is local ``wall clock'' time, `s' if the given time is local ``standard'' time, or `u' (or `g' or `z') if the given time is universal time; in the absence of an indi- cator, wall clock time is assumed. SAVE Give the amount of time to be added to local standard time when the rule is in effect. This field has the same format as the AT field (although, of course, the `w' and `s' suffixes are not used). LETTER/S Give the ``variable part'' (for example, the ``S'' or ``D'' in ``EST'' or ``EDT'') of time zone abbreviations to be used when this rule is in effect. If this field is -, the variable part is null. A zone line has the form: Zone NAME GMTOFF RULES/SAVE FORMAT [UNTILYEAR [MONTH [DAY [TIME]]]] For example: Zone Australia/Adelaide 9:30 Aus CST 1971 Oct 31 2:00 The fields that make up a zone line are: NAME The name of the time zone. This is the name used in creating the time conversion information file for the zone. GMTOFF The amount of time to add to UTC to get standard time in this zone. This field has the same format as the AT and SAVE fields of rule lines; begin the field with a minus sign if time must be subtracted from UTC. RULES/SAVE The name of the rule(s) that apply in the time zone or, alter- nately, an amount of time to add to local standard time. If this field is - then standard time always applies in the time zone. FORMAT The format for time zone abbreviations in this time zone. The pair of characters %s is used to show where the ``variable part'' of the time zone abbreviation goes. Alternately, a slash (/) separates standard and daylight abbreviations. UNTILYEAR [MONTH [DAY [TIME]]] The time at which the UTC offset or the rule(s) change for a location. It is specified as a year, a month, a day, and a time of day. If this is specified, the time zone information is gen- erated from the given UTC offset and rule change until the time specified. The month, day, and time of day have the same format as the IN, ON, and AT fields of a rule; trailing fields can be omitted, and default to the earliest possible value for the miss- ing fields. The next line must be a ``continuation'' line; this has the same form as a zone line except that the string ``Zone'' and the name are omitted, as the continuation line will place information starting at the time specified as the until information in the previous line in the file used by the previous line. Continua- tion lines may contain until information, just as zone lines do, indicating that the next line is a further continuation. A link line has the form Link LINK-FROM LINK-TO For example: Link Europe/Istanbul Asia/Istanbul The LINK-FROM field should appear as the NAME field in some zone line; the LINK-TO field is used as an alternate name for that zone. Except for continuation lines, lines may appear in any order in the input. Lines in the file that describes leap seconds have the following form: Leap YEAR MONTH DAY HH:MM:SS CORR R/S For example: Leap 1974 Dec 31 23:59:60 + S The YEAR, MONTH, DAY, and HH:MM:SS fields tell when the leap second hap- pened. The CORR field should be ``+'' if a second was added or ``-'' if a second was skipped. The R/S field should be (an abbreviation of) ``Stationary'' if the leap second time given by the other fields should be interpreted as UTC or (an abbreviation of) ``Rolling'' if the leap second time given by the other fields should be interpreted as local wall clock time. EXTENDED EXAMPLE Here is an extended example of zic input, intended to illustrate many of its features. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Swiss 1940 only - Nov 2 0:00 1:00 S Rule Swiss 1940 only - Dec 31 0:00 0 - Rule Swiss 1941 1942 - May Sun>=1 2:00 1:00 S Rule Swiss 1941 1942 - Oct Sun>=1 0:00 0 Rule EU 1977 1980 - Apr Sun>=1 1:00u 1:00 S Rule EU 1977 only - Sep lastSun 1:00u 0 - Rule EU 1978 only - Oct 1 1:00u 0 - Rule EU 1979 1995 - Sep lastSun 1:00u 0 - Rule EU 1981 max - Mar lastSun 1:00u 1:00 S Rule EU 1996 max - Oct lastSun 1:00u 0 - # Zone NAME GMTOFF RULES FORMAT UNTIL Zone Europe/Zurich 0:34:08 - LMT 1848 Sep 12 0:29:44 - BMT 1894 Jun 1:00 Swiss CE%sT 1981 1:00 EU CE%sT Link Europe/Zurich Switzerland In this example, the zone is named Europe/Zurich but it has an alias as Switzerland. Zurich was 34 minutes and 8 seconds west of GMT until 1848-09-12 at 00:00, when the offset changed to 29 minutes and 44 sec- onds. After 1894-06-01 at 00:00 Swiss daylight saving rules (defined with lines beginning with "Rule Swiss") apply, and the GMT offset became one hour. From 1981 to the present, EU daylight saving rules have applied, and the UTC offset has remained at one hour. In 1940, daylight saving time applied from November 2 at 00:00 to Decem- ber 31 at 00:00. In 1941 and 1942, daylight saving time applied from the first Sunday in May at 02:00 to the first Sunday in October at 00:00. The pre-1981 EU daylight-saving rules have no effect here, but are included for completeness. Since 1981, daylight saving has begun on the last Sunday in March at 01:00 UTC. Until 1995 it ended the last Sunday in September at 01:00 UTC, but this changed to the last Sunday in October starting in 1996. For purposes of display, "LMT" and "BMT" were initially used, respec- tively. Since Swiss rules and later EU rules were applied, the display name for the timezone has been CET for standard time and CEST for day- light saving time. NOTES For areas with more than two types of local time, you may need to use local standard time in the AT field of the earliest transition time's rule to ensure that the earliest transition time recorded in the compiled file is correct. If, for a particular zone, a clock advance caused by the start of day- light saving coincides with and is equal to a clock retreat caused by a change in UTC offset, zic produces a single transition to daylight saving at the new UTC offset (without any change in wall clock time). To get separate transitions use multiple zone continuation lines specifying transition instants using universal time.
Guy Harris <guy@alum.mit.edu> writes:
On Aug 17, 2020, at 12:01 PM, Juergen Naeckel via tz <tz@iana.org> wrote:
First of all, a tar.gz is Linux specific. True, you could install additional Windows software. But, that might not go well with customers of mine. I think a ZIP would be acceptable for both worlds.
...offering both a tarball and a zipball might be a good idea (zip exists as a UN*X command, and ships with at least UN*Xes, but UN*X users may be less used to it).
While there's nothing particularly wrong with providing a zip-format archive if Paul and Tim feel like doing so, I find myself skeptical that there's actually a need for that. The primary tzdata distribution is *not* oriented towards the sort of end user who might find the lack of a zipball to be an impediment. Rather, that dataset is meant to be consumed by OS-level packagers who will then push it out in system updates for their respective platforms. (Hello, Microsoft?) I recall prior discussion in this list to the effect that the iana.org website is simply not provisioned to the point where lots of individual users directly downloading the data could be supported. So being mass market friendly seems like an anti-goal. regards, tom lane
On Aug 18, 2020, at 8:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
While there's nothing particularly wrong with providing a zip-format archive if Paul and Tim feel like doing so, I find myself skeptical that there's actually a need for that. The primary tzdata distribution is *not* oriented towards the sort of end user who might find the lack of a zipball to be an impediment. Rather, that dataset is meant to be consumed by OS-level packagers who will then push it out in system updates for their respective platforms. (Hello, Microsoft?)
Unfortunately, Juergen may be working on the platform developed by the company you're addressing in that comment. I also infer from "I have to implement something in JavaScript that uses timezones.", in his original message, that he's not an "end user" in the sense of somebody just wanting to update their system's time zone files (which, as per the way you addressed the developer of the system, don't exist anyway :-)). However, what he said later was
First of all, a tar.gz is Linux specific. True, you could install additional Windows software. But, that might not go well with customers of mine. I think a ZIP would be acceptable for both worlds.
If he's providing software to a customer base, he might want to consider bundling the tzdb with the JavaScript software; even if the customer has a zipball, it'd be a pain for them to download and install.
On 2020-08-18 22:02, Guy Harris wrote:
On Aug 18, 2020, at 8:43 PM, Tom Lane wrote:
While there's nothing particularly wrong with providing a zip-format archive if Paul and Tim feel like doing so, I find myself skeptical that there's actually a need for that. The primary tzdata distribution is *not* oriented towards the sort of end user who might find the lack of a zipball to be an impediment. Rather, that dataset is meant to be consumed by OS-level packagers who will then push it out in system updates for their respective platforms. (Hello, Microsoft?)
Unfortunately, Juergen may be working on the platform developed by the company you're addressing in that comment.
I also infer from "I have to implement something in JavaScript that uses timezones.", in his original message, that he's not an "end user" in the sense of somebody just wanting to update their system's time zone files (which, as per the way you addressed the developer of the system, don't exist anyway :-)).
However, what he said later was
First of all, a tar.gz is Linux specific. True, you could install additional Windows software. But, that might not go well with customers of mine. I think a ZIP would be acceptable for both worlds.
If he's providing software to a customer base, he might want to consider bundling the tzdb with the JavaScript software; even if the customer has a zipball, it'd be a pain for them to download and install.
J DOT N AT Adobe.com - possibly Javascript embedded in a [PDF] file - maybe form filling? Even xz compressed tzdb binaries occupy over 200KB - compressed sources 230KB+ (320+KB for zip) - sources nearly 1MB. Javascript implementations should use system timezones and locales, to avoid burdening the user with updates, as well as adapting to the user's preferences - this one should do the same. There are probably libraries with permissive BSD/MIT licences to access Windows tz info and others to access tzdb that the OP could port or adapt. Windows tz info won't help you much with history the last time I looked, and tzdb is most accurate after 1970. Windows time zone and "dynamic" (dated) zone info is well documented on the MS site and you can display it using the Windows command: $ reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones" /s /z Systems I have admin control over show dates as e.g. 2020 Aug 19 Wed 12:23:19+0600 (except Windows won't include the time zone offset as it has no user specifiable controls for that) - this one should do the same. On 2020-08-18 22:13, Paul Eggert wrote:
On 8/17/20 12:01 PM, Juergen Naeckel via tz wrote:>> First of all, a tar.gz is Linux specific.> Not really; the format is natively supported by lots of operating systems, including macOS and Microsoft Windows 10. Windows supports [BSD]tar on the command line: it was (relatively) unannounced and unknown to me (and probably many others) until this; from its date, it may have been added in the 2019-04 update! Windows also supports zip in Explorer or newer Powershell, and cab with makecab/expend.
On 2020-08-19 11:44, Guy Harris wrote:
On Aug 19, 2020, at 8:41 AM, Paul Gilmartin wrote:>> And Single UNIX much prefers "pax" over "tar" nowadays.> "prefers" in what sense? And, in practice, how many pax archives using its extensions to ustar format are out there? As for pax - I have heard of of it but have never come across anyone else who even mentioned it or used it (except in man pages) and I don't remember noticing if any distro installed it by default. POSIX invented something that wasn't as good or useful as what was already available by the time it was implemented.
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
On 2020-08-18, at 21:28:09, Guy Harris wrote:
On Aug 17, 2020, at 12:01 PM, Juergen Naeckel via wrote:
... However… First of all, a tar.gz is Linux specific.
Or, rather, UN*X specific; Linux Torvalds was about 10 years old when tar was first broadly available (with V7 in 1979, I think), and gzip came out a little more than a year after somebody announced that they were "doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones", although it did support bash and gcc when that announcement was made. :-)
".gz" is non-POSIX. z/OS UNIX doesn't supply a gzip or zip. And Single UNIX much prefers "pax" over "tar" nowadays.
But...
True, you could install additional Windows software. But, that might not go well with customers of mine. I think a ZIP would be acceptable for both worlds.
I suspect WinZip is tar-savvy. But is WinZip in base Windows? (Cygwin rules!)
...offering both a tarball and a zipball might be a good idea (zip exists as a UN*X command, and ships with at least UN*Xes, but UN*X users may be less used to it).
Again, non-POSIX, but distributed with (most) Linux. Various zip software may differ in treatment of symlinks and directory links. Info-ZIP for example, expands links unless an option is supplied. - gil
On Aug 19, 2020, at 8:41 AM, Paul Gilmartin <PaulGBoulder@AIM.com> wrote:
On 2020-08-18, at 21:28:09, Guy Harris wrote:
On Aug 17, 2020, at 12:01 PM, Juergen Naeckel via wrote:
... However… First of all, a tar.gz is Linux specific.
Or, rather, UN*X specific; Linux Torvalds was about 10 years old when tar was first broadly available (with V7 in 1979, I think), and gzip came out a little more than a year after somebody announced that they were "doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones", although it did support bash and gcc when that announcement was made. :-)
".gz" is non-POSIX. z/OS UNIX doesn't supply a gzip or zip.
Non-POSIX but supplied with many UN*Xes; in practice, *not* supporting it will get in the way of using a lot of source tarballs out there - for that matter, a UN*X supplier is best advised to offer bzip2 and xzip decompression as well, these days. And does Z/OS UNIX use EBCDIC rather than ASCII? If so, it may be a UNIX, but it's a UNIX for which a lot of code written for UN*Xes may not work, although the tz code might have avoided making ASCII-specific assumptions.
And Single UNIX much prefers "pax" over "tar" nowadays.
"prefers" in what sense? And, in practice, how many pax archives using its extensions to ustar format are out there?
...offering both a tarball and a zipball might be a good idea (zip exists as a UN*X command, and ships with at least UN*Xes, but UN*X users may be less used to it).
Again, non-POSIX, but distributed with (most) Linux.
And at least some non-Linux UN*Xes: $ which unzip /usr/bin/unzip $ uname -sr Darwin 19.6.0
On 2020-08-19, at 11:44:45, Guy Harris wrote:
And does Z/OS UNIX use EBCDIC rather than ASCII? If so, it may be a UNIX, but it's a UNIX for which a lot of code written for UN*Xes may not work, although the tz code might have avoided making ASCII-specific assumptions.
Absolutely true, only slightly mitigated in that z/OS pax embeds code conversion, as does Info-ZIP "unzip -aa". It leaves the problem "a lot of code written for UN*Xes may not work, ..."
And Single UNIX much prefers "pax" over "tar" nowadays.
"prefers" in what sense? And, in practice, how many pax archives using its extensions to ustar format are out there?
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/toc.html ... mentions "pax", not "tar".
...offering both a tarball and a zipball might be a good idea (zip exists as a UN*X command, and ships with at least UN*Xes, but UN*X users may be less used to it).
Again, non-POSIX, but distributed with (most) Linux.
And at least some non-Linux UN*Xes:
Yes. -- gil
On 8/17/20 12:01 PM, Juergen Naeckel via tz wrote:
First of all, a tar.gz is Linux specific.
Not really; the format is natively supported by lots of operating systems, including macOS and Microsoft Windows 10.
I definitely do not consider MAKEFILE and .awk file as part of a “data only distribution”.
This is more a problem with the labeling than with the contents. The data distribution is intended to include not just the data, but also makefiles etc. useful to install the data. To avoid future confusion, it sounds like <https://www.iana.org/time-zones> should change the phrase "Data Only Distribution" to "Data Distribution", and likewise for "Code Only Distribution".
I had read the readme file but it didn’t explain the data I saw in the files.
The attached patch to README should help with that; I've added that to the development version. I think others addressed your other questions. Thanks for your comments.
participants (14)
-
Brian Inglis -
Eliot Lear -
Guy Harris -
Guy Harris -
Juergen Naeckel -
Ken Murchison -
Lester Caine -
Martin Burnicki -
Matt Johnson-Pint -
Michael Douglass -
Paul Eggert -
Paul Gilmartin -
Tim Parenti -
Tom Lane