Inappropriate project direction
In the last few years, the following changes have been made to the tzdb project. Each of these - added no value - had a cost that far exceeded the benefits - should not have happened 1) Removal of Zone definitions from many countries. While the Zone definitions may have been the same across different countries, it was never appropriate to merge the time-zones of multiple different countries (backzone being the result). - the change caused LMT values to be lost - downstream consumers had to change logic wrt the meaning of backzone - it was culturally insensitive to not provide a primary Zone entry for some countries 2) Removal of textual short zone names. While these names may well have been invented in some cases, the had often become de facto standards - end-users complained about the loss of textual names - downstream consumers had to change logic to handle numeric-style identifiers 3) Move to a niche archive format The main archive format was changed from the well-known and widely supported gz to the niche lz format. There was and is no justification for using a niche format on a project as important as this one. - downstream consumers need to find and use the niche format - Windows does not have proper support for the niche format 4) Negative SAVE values Despite being a known fact in tzdb since 2005, and despite being warned not to in advance, a decision to re-interpret the meaning of Ireland DST was pushed through. - downstream consumers broke - the interaction with CLDR is incompatible with negative DST - the change has no impact on actual times - even if someone thought it was broken, there are no benefits to making the change 5) Fractional seconds A desire to fix subsecond data from over 50 years ago. - downstream consumers will break - the number of people who care is vanishingly small Were recent discussions a one-off, I might be prepared to let things lie, but as can be seen, there is a pattern here. Not one of these changes has added value to the project. Not one of them has been necessary to the primary mission of recording what governments are doing to their clocks now, nor even in the last 40 years. Worse, the majority are driven by a notion that getting the data "pure" trumps all problems reported by downstream consumers. It is long past time to accept that tzdb needs to focus on the primary mission - recording current government changes in a stable, backwards compatible manner. Tinkering needs to stop. Stephen
You seem to think stability is the only thing that matters, but it is clearly a balancing act between accuracy and stability. There have been repeated efforts to work out some compatibility mechanism for software broken by these "changes" (some are not really changes at all just incorrect assumptions made that happened not to have been violated before), and your response has been to just demand (none too kindly, for that matter) that zero changes ever happen in the future and no upgrade mechanism be provided. If you need an unchanging version is this frozen in time and *cannot* use the compatibility versions for whatever reason, I suggest that you maintain a fork of the project. It wouldn't be amazingly difficult, you just would need to maintain a "downgrade" script and you'd still be able to take advantage of all the hard work of the volunteers maintaining this project without any of the pesky changes to improve the accuracy of the data. On February 6, 2018 4:13:51 PM UTC, Stephen Colebourne <scolebourne@joda.org> wrote:
In the last few years, the following changes have been made to the tzdb project. Each of these
- added no value - had a cost that far exceeded the benefits - should not have happened
1) Removal of Zone definitions from many countries.
While the Zone definitions may have been the same across different countries, it was never appropriate to merge the time-zones of multiple different countries (backzone being the result).
- the change caused LMT values to be lost - downstream consumers had to change logic wrt the meaning of backzone - it was culturally insensitive to not provide a primary Zone entry for some countries
2) Removal of textual short zone names.
While these names may well have been invented in some cases, the had often become de facto standards
- end-users complained about the loss of textual names - downstream consumers had to change logic to handle numeric-style identifiers
3) Move to a niche archive format
The main archive format was changed from the well-known and widely supported gz to the niche lz format. There was and is no justification for using a niche format on a project as important as this one.
- downstream consumers need to find and use the niche format - Windows does not have proper support for the niche format
4) Negative SAVE values
Despite being a known fact in tzdb since 2005, and despite being warned not to in advance, a decision to re-interpret the meaning of Ireland DST was pushed through.
- downstream consumers broke - the interaction with CLDR is incompatible with negative DST - the change has no impact on actual times - even if someone thought it was broken, there are no benefits to making the change
5) Fractional seconds
A desire to fix subsecond data from over 50 years ago.
- downstream consumers will break - the number of people who care is vanishingly small
Were recent discussions a one-off, I might be prepared to let things lie, but as can be seen, there is a pattern here. Not one of these changes has added value to the project. Not one of them has been necessary to the primary mission of recording what governments are doing to their clocks now, nor even in the last 40 years. Worse, the majority are driven by a notion that getting the data "pure" trumps all problems reported by downstream consumers.
It is long past time to accept that tzdb needs to focus on the primary mission - recording current government changes in a stable, backwards compatible manner.
Tinkering needs to stop.
Stephen
I solely ended up as an end-user, but.. Stephen Colebourne <scolebourne@joda.org> wrote: |In the last few years, the following changes have been made to the |tzdb project. Each of these You did not mention large code cleanup and fight against bit rotting. |- added no value |- had a cost that far exceeded the benefits |- should not have happened | |1) Removal of Zone definitions from many countries. | |While the Zone definitions may have been the same across different |countries, it was never appropriate to merge the time-zones of |multiple different countries (backzone being the result). | |- the change caused LMT values to be lost |- downstream consumers had to change logic wrt the meaning of backzone |- it was culturally insensitive to not provide a primary Zone entry |for some countries | |2) Removal of textual short zone names. | |While these names may well have been invented in some cases, the had |often become de facto standards | |- end-users complained about the loss of textual names |- downstream consumers had to change logic to handle numeric-style \ |identifiers In the end i have been convinced that zone names and abbreviations and the TZDB sources as they are today have nothing much in common. I just never happened to realize that because i was fine with what i got for the Germany that i live in. I would have loved to know that earlier and being given the data to do better via TZDB - but that is not the case and i am not the one to improve this situation either. |3) Move to a niche archive format | |The main archive format was changed from the well-known and widely |supported gz to the niche lz format. There was and is no justification |for using a niche format on a project as important as this one. | |- downstream consumers need to find and use the niche format |- Windows does not have proper support for the niche format Yes i do not like that either, given that xz is far more common and zstd is seeing more usage over time. It may be that it has archive format advantages over the former. That is a GNU project decision and Paul Eggert is one of _the_ GNU contributors. Also, .gz is supported, it is just the big all-in-one ball which uses that format. |4) Negative SAVE values | |Despite being a known fact in tzdb since 2005, and despite being I do not know what this means, i was working back then? |warned not to in advance, a decision to re-interpret the meaning of |Ireland DST was pushed through. | |- downstream consumers broke |- the interaction with CLDR is incompatible with negative DST |- the change has no impact on actual times |- even if someone thought it was broken, there are no benefits to |making the change Yes, the code i had would have been broken by this change, too. I guess it was one more of those bugs that i produced, if the POSIX standard supports negative DST... |5) Fractional seconds | |A desire to fix subsecond data from over 50 years ago. | |- downstream consumers will break |- the number of people who care is vanishingly small Yes but here i step in and say that i truly like the decision, i always thought TZDB is a community effort to track the history of local time, and if there is such an offset then, well, it was. There were so many false times in this DB, which i did not know either, many of them have been corrected in the last years, thanks to sleuthering of Paul Eggert and occasionally also other people! Of course my thing could not deal with that and possibly some magical comment or an additional field at the end of line should be used to notify consumers which can about such subprecisions. Actually adding subsecond precision via dot separator would be the most easy thing to implement for my one, but it had to be done of course. |Were recent discussions a one-off, I might be prepared to let things |lie, but as can be seen, there is a pattern here. Not one of these |changes has added value to the project. Not one of them has been |necessary to the primary mission of recording what governments are |doing to their clocks now, nor even in the last 40 years. Worse, the |majority are driven by a notion that getting the data "pure" trumps |all problems reported by downstream consumers. | |It is long past time to accept that tzdb needs to focus on the primary |mission - recording current government changes in a stable, backwards |compatible manner. | |Tinkering needs to stop. Se vogliamo che tutto rimanga come è, bisogna che tutto cambi. If we want that everything remains the same, it all has to change. --Giuseppe Tomasi di Lampedusa Ciao. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Not weighing in on the overall debate, just adding some technical bits ... Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
Stephen Colebourne <scolebourne@joda.org> wrote: |3) Move to a niche archive format | |The main archive format was changed from the well-known and widely |supported gz to the niche lz format. There was and is no justification |for using a niche format on a project as important as this one. | |- downstream consumers need to find and use the niche format |- Windows does not have proper support for the niche format
Yes i do not like that either, given that xz is far more common and zstd is seeing more usage over time. It may be that it has archive format advantages over the former.
Ignoring the compressor and/or archiver aspect**, and ... Ignore whether adding an LZ77-based compressor (gzip) was justified ... If one is going to add an LZMA container-based compressor (e.g., 7z, xz, lzip, et al), if portability and longevity are paramount, then lzip is probably best. Although xz finally added some POSIX meta that 7z lacked, it's still not something I'd recommend when exchanging between various POSIX (let alone non-POSIX) systems. E.g., I only use xz with tar when I'm sending data to be used on the same POSIX architecture/platform, and not for long-term retention. lzip is really the first real attempt -- not not saying it is, but it is the first, real attempt -- at an universal POSIX archive standard. Which brings me to ...
That is a GNU project decision and Paul Eggert is one of _the_ GNU contributors.
There is still a heavy copyleft (e.g., GPL) v. non-copyleft FLOSS debate that rages on, with various people putting various values -- from nothing to everything -- on that. lzip -- or more problematic, it's lzlib -- is GPLv2 -- not even LGPL -- which has some asterisks for commercial developers. I don't know the state of public domain lzip (pdlzip), but it seems to be good enough for any decompression (and most general compression). Lastly ...
Also, .gz is supported, it is just the big all-in-one ball which uses that format.
I don't see projects dropping LZ77-based compressors anytime soon. If they want to add a 2nd format option, then that's going to happen, and debates will rage. However, I also expect the GNU Project or pro-copyleft maintainers to push a GNU solution over others. So lzip isn't surprising. - bjs **P.S. The other bit is that lzip -- like everything from legacy LZ77-based PKZip to LZMA2 7-Zip -- actually focuses on compressing a file into an archive, instead of being a streaming compressor for either files or an archive. Yes, it's not very UNIX-like to do that, but there are too many advantages with it to ignore. It's a common approach on Windows, since Windows never provided a native archiving (w/o compression) approach, unlike UNIX system. E.g., years ago, when linear access (tape) was common, I used to use afio for per-file compression, over a compressed cpio stream (of files in the archive), to backup (to tape). It offered too many advantages, all while being cpio compatible (if cpio was used to extract, then it was a stream of compressed files). Several of these advantages still exist, like better handling of multi-volume archives (no different than in the days of tape). I was hopeful the "Austin Group" of IEEE POSIX + XOpen SuS lineage/workgroup would have addressed this for the 21st century, or at least defined an archiver that could do compression on a per-file basis, even if the compressor choice was still external. But instead, we got 'pax' which just 'punted' (I'll use the popular, American reference) the problem, and why 'tar' is still popular. -- Bryan J Smith - http://www.linkedin.com/in/bjsmith E-mail: b.j.smith at ieee.org or me at bjsmith.me
Bryan Smith <b.j.smith@ieee.org> wrote: |Not weighing in on the overall debate, just adding some technical bits ... | |Steffen Nurpmeso <steffen@sdaoden.eu> wrote: |> Stephen Colebourne <scolebourne@joda.org> wrote: |>|3) Move to a niche archive format |>| |>|The main archive format was changed from the well-known and widely |>|supported gz to the niche lz format. There was and is no justification |>|for using a niche format on a project as important as this one. |>| |>|- downstream consumers need to find and use the niche format |>|- Windows does not have proper support for the niche format |> |> Yes i do not like that either, given that xz is far more common |> and zstd is seeing more usage over time. It may be that it has |> archive format advantages over the former. | |Ignoring the compressor and/or archiver aspect**, | and ... |Ignore whether adding an LZ77-based compressor (gzip) was justified ... | |If one is going to add an LZMA container-based compressor (e.g., 7z, |xz, lzip, et al), if portability and longevity are paramount, then |lzip is probably best. Although xz finally added some POSIX meta that |7z lacked, it's still not something I'd recommend when exchanging |between various POSIX (let alone non-POSIX) systems. | |E.g., I only use xz with tar when I'm sending data to be used on the |same POSIX architecture/platform, and not for long-term retention. |lzip is really the first real attempt -- not not saying it is, but it |is the first, real attempt -- at an universal POSIX archive standard. I am very much surprised by the latter statement. There is pax, now with three uncompressed formats (ustar, cpio..). And below. I have no idea on the standardizing issue, just noting that zstd is the only good outcome of an american company that i know about and the first thing that i use. It is BSD licensed and has an additional patent grant, and it is now used by e.g. the FreeBSD kernel because it can be very fast or compress very good. Though not so good as the mentioned. Longevity is a real problem. I think only data duplication and overall checksumming will do that. Darkness and other defined environmental parameters; e.g., in Germany we have the «Barbarastollen» underground archive (with false Wikipedia if i trust the german Wikipedia, as it is buried only 200 metres under earth and thus soon subject of new warheads me thinks). I have never looked and compared header and data chunk checksumming of any of the compressors etc. that is mentioned here. I am sure you need overall plus chunk including header checksumming plus data repititions in order to get something useful. Correcting 1-bit errors is possibly a theoretical issue. Multiple copies on distinct places looks better. That makes me realize that the american nuclear missile launch system still used floppy disks for the keys last year, unless this was a duck or what is the name for fake news over there. All very volatile. If i recall, bitsavers.org have also lost funding or priority, or both.. |Which brings me to ... | |> That is a GNU project decision and Paul Eggert is one of _the_ |> GNU contributors. | |There is still a heavy copyleft (e.g., GPL) v. non-copyleft FLOSS |debate that rages on, with various people putting various values -- |from nothing to everything -- on that. lzip -- or more problematic, |it's lzlib -- is GPLv2 -- not even LGPL -- which has some asterisks |for commercial developers. I don't know the state of public domain |lzip (pdlzip), but it seems to be good enough for any decompression |(and most general compression). | |Lastly ... | |> Also, .gz is supported, it is just the big all-in-one ball which \ |> uses that format. | |I don't see projects dropping LZ77-based compressors anytime soon. If |they want to add a 2nd format option, then that's going to happen, and |debates will rage. | |However, I also expect the GNU Project or pro-copyleft maintainers to |push a GNU solution over others. So lzip isn't surprising. | |- bjs | |**P.S. The other bit is that lzip -- like everything from legacy |LZ77-based PKZip to LZMA2 7-Zip -- actually focuses on compressing a |file into an archive, instead of being a streaming compressor for |either files or an archive. Yes, it's not very UNIX-like to do that, |but there are too many advantages with it to ignore. It's a common |approach on Windows, since Windows never provided a native archiving |(w/o compression) approach, unlike UNIX system. | |E.g., years ago, when linear access (tape) was common, I used to use |afio for per-file compression, over a compressed cpio stream (of files |in the archive), to backup (to tape). It offered too many advantages, |all while being cpio compatible (if cpio was used to extract, then it |was a stream of compressed files). Several of these advantages still |exist, like better handling of multi-volume archives (no different |than in the days of tape). | |I was hopeful the "Austin Group" of IEEE POSIX + XOpen SuS |lineage/workgroup would have addressed this for the 21st century, or |at least defined an archiver that could do compression on a per-file |basis, even if the compressor choice was still external. But instead, |we got 'pax' which just 'punted' (I'll use the popular, American |reference) the problem, and why 'tar' is still popular. I do not like pax command line (either). Puuh, yes, this is very dense. Well, a series of competing stream compressors to be used on an archive, not like zip which is an all-in-one and now offers compression equal to or bettern than ARJ or RAR whick were better in the 90s when i was using Windows/4DOS. Compression of an archive as a whole will always be better than compressing individual members, sufficient window size provided. Of course. The nice thing with the UNIX approach is that you can easily create anything from a script to a C program to create what you want with POSIX standardized components, if compress a.k.a. Lempel-Ziv / Lempel-Ziv-Welch is good enough. It likely is not today. The pax ustar interchange subformat has a simple checksum. That as well as cksum(1) as such would benefit from better algorithms. Note that FreeBSD just now introduces CRC-32 checksums to the UFS file system, for an upcoming release. Maybe the future will bring an extension to compress or a new set of tools to achieve better compression. But then i personally, just in case it mattered, would vote for a software that scales to needs from fast to small as good as the one i mentioned does, from almost as fast as lz4 (while compressing better and thus also requiring more energe) to compressing almost as good as xz or lzip, ending up as an universal tool, which is preferable for a standard in my eyes. Have a nice day. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
...
5) Fractional seconds
A desire to fix subsecond data from over 50 years ago.
- downstream consumers will break - the number of people who care is vanishingly small
Were recent discussions a one-off, I might be prepared to let things lie, but as can be seen, there is a pattern here. Not one of these changes has added value to the project. Not one of them has been necessary to the primary mission of recording what governments are doing to their clocks now, nor even in the last 40 years. Worse, the majority are driven by a notion that getting the data "pure" trumps all problems reported by downstream consumers. ...
also add changing UTC to UT, despite (almost?) all current zones are derived from UTC explicitly and 'UT' itself is unclear whether it means UT0, UT1(R), UT2 or even UTC I, for one, live in UTC+1 zone, not UT+1 like tools dealing with tz now incorrectly show me, please read the legislation ... ok, I cannot quickly find anything for CZ, I guess Germany will do too: http://www.cl.cam.ac.uk/~mgk25/time/zeitgesetz.en.html
§ 1 Legal time (2) Legal time is Central European Time. It is defined as Coordinated Universal Time plus one hour. <<<
repeat: "It is defined as *Coordinated Universal Time* plus one hour." not just 'Universal Time' but 'Coordinated Universal Time', and the following definition agrees with UTC, not UT[012]:
(3) Coordinated Universal Time is defined as a time scale with the following properties:
On 1 January 1972, 0 hours, it corresponds to 31 December 1971, 23 hours, 59 minutes, 59.96 seconds mean solar time on the null meridian. The scale unit is the base unit second according to section 3 paragraph 4 of the act on units of measurement of 2 July 1969 (BGBl. I, p. 709), last amended by article 287 number 48 of the act of 2 March 1974 (BGBl. I, p. 469), at sea level. The time scale Coordinated Universal Time is kept in alignment with mean solar time at the null meridian with a tolerance of not more than one second, either by inserting one additional second or by omitting one second. <<< K. -- Karel Volný BaseOS QE - Daemons Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) :: "Never attribute to malice what can :: easily be explained by stupidity."
Karel Volný <kvolny@redhat.com> wrote: |... |also add changing UTC to UT, despite (almost?) all current zones are |derived from UTC explicitly and 'UT' itself is unclear whether it means |UT0, UT1(R), UT2 or even UTC ... |I, for one, live in UTC+1 zone, not UT+1 like tools dealing with tz now |incorrectly show me, please read the legislation |... ok, I cannot quickly find anything for CZ, I guess Germany will do too: I live almost in UT1+1 because many people care to keep me there. And i am pretty sure Slav women like that the same that i do. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On Thu 2018-02-08T14:54:02+0100 Karel Volný hath writ:
also add changing UTC to UT, despite (almost?) all current zones are derived from UTC explicitly and 'UT' itself is unclear whether it means UT0, UT1(R), UT2 or even UTC
I, for one, live in UTC+1 zone, not UT+1 like tools dealing with tz now incorrectly show me, please read the legislation ... ok, I cannot quickly find anything for CZ, I guess Germany will do too:
The current EU directive on summer time is http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32000L0084 In that we see that the EU bureaucrats have not seen necessity to be consistent about whether they mean Greenwich, Universal, or Coordinated. As far as they are concerned, they are all synonymous. Some multi-lingual countries use one term in one official language and a different term in another official language. For CS it says GMT and for SK it says Greenwich Mean Time.
repeat: "It is defined as *Coordinated Universal Time* plus one hour."
Yes, that is the translation of the German version. German astronomers were present at the 1928 IAU meeting which coined the phrase Universal Time. They then chose their own language-specific word. In contrast to other countries, the connections between the German legislators and the PTB have remained strong enough to refine that definition in the wording of the law over the decades. A summary of the wording for the time base in each member country is in http://www.ucolick.org/~sla/leapsecs/seago.pdf This is one of the technical aspects that governments tend not to write into law but rather leave as an implementation detail to be handled by the geeks who run their national time infrastructure. This is much like the decimal seconds discussion where tzdb will end up recording what time offset people believed they were using even in cases where the subsequent metrology shows that they were wrong. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On 02/08/2018 06:41 PM, Steve Allen wrote:
The current EU directive on summer time is http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32000L0084
In that we see that the EU bureaucrats have not seen necessity to be consistent about whether they mean Greenwich, Universal, or Coordinated.
Maybe they can figure out while the European Parliament is asking for a review anyway: http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//TEXT+TA+P8-TA-20... http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//NONSGML+TA+P8-TA... Andreas -- Andreas Stieger <astieger@suse.com> Project Manager Security SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
Andreas Stieger <astieger@suse.com> wrote: |On 02/08/2018 06:41 PM, Steve Allen wrote: |> The current EU directive on summer time is |> http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32000L0084 |> |> In that we see that the EU bureaucrats have not seen necessity to be |> consistent about whether they mean Greenwich, Universal, or Coordinated. | |Maybe they can figure out while the European Parliament is asking for a |review anyway: |http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//TEXT+TA+P8-TA-20\ |18-0043+0+DOC+XML+V0//EN&language=EN |http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//NONSGML+TA+P8-TA\ |-2018-0043+0+DOC+PDF+V0//EN Want to get rid of DST, but that does not change the meaning of time. It says "numerous scientific studies" "have instead indicated the existence of negative effects on human health" regarding to DST. Sometimes i am a bit afraid when i have to face such major overengineering, given that we no longer need wale hunting for blubber but only need to look at a lot of first world kids, not to talk about the massive abuse of medication and, puuh, alcohol, one of the "three most dangerous drugs" i guess. Plastics, industrial pollution, etc. Wow. That mix even revives zombies. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On 02/06/2018 08:13 AM, Stephen Colebourne wrote:
it was never appropriate to merge the time-zones of multiple different countries (backzone being the result).
- the change caused LMT values to be lost
Those LMT values were not significant and their loss was no real loss. The only significant effect that I recall was on test suites, and test suites should not be forcing tzdb to continue to promote invented data.
- downstream consumers had to change logic wrt the meaning of backzone Downstream consumers don't have worry about backzone. Mostly, they should just not use backzone, as it is outside the scope of tzdb proper and contains data that is not installed by default.
- it was culturally insensitive to not provide a primary Zone entry for some countries tzdb focuses on timekeeping practices. We should spend as few of our limited resources as possible to worry about political or cultural sensitivities that have nothing to do with timekeeping proper. Although we cannot exclude politics entirely, we should strive to not complicate the database merely to make political partisans happy, a task that would be never-ending.
2) Removal of textual short zone names.
While these names may well have been invented in some cases, the had often become de facto standards The few invented abbreviations that became common parlance were kept. The remaining abbreviations lacked sufficient practical justification for a database where the goal is to describe timekeeping practice, not prescribe it.
- downstream consumers had to change logic to handle numeric-style identifiers Applications like OpenJDK+CLDR that want abbreviations and full names for every time zone needed to maintain their own databases of inventions anyway. For tzdb-style abbreviations, numeric identifiers are more accurate and less error-prone than invented ones, and have been part of the POSIX standard since 2001.
The main archive format was changed from the well-known and widely supported gz to the niche lz format. This has not affected downstream consumers, which can continue to use gzip format as before. Support for lzip is easily and freely available on modern platforms, including MS-Windows. Microsoft itself didn't support gzip back in the day, but that didn't mean we shouldn't have used gzip back then.
4) Negative SAVE values ... - downstream consumers broke The main downstream consumer that broke was OpenJDK+CLDR. The problem was soon rectified, and because OpenJDK+CLDR is an important enough consumer we now have a way in the development version to generate a form of the tzdata source that does not use negative DST offsets. That being said, the OpenJDK+CLDR model is incorrect for Irish timekeeping and it really should get fixed at some point. Fractional seconds are a similar sort of thing, though here CLDR has made it clear that they don't care about timestamps before 1990, so this issue should not affect CLDR (unless North Korea starts using a fractional-second UTC offset :-) and only a trivial change to OpenJDK should be needed.
Not one of these changes has added value to the project. Even if there was no value to you, there is some value to record civil timekeeping more accurately. Different consumers have different needs in this area.
More importantly, there needs to be a better way for tzdb+OpenJDK+CLDR to accommodate future changes, as there inevitably will be. Of course we should not change things just for the purpose of changing. Conversely, it would not be healthy to have a software system that can never be changed and can never be improved. We should have a reasonable upgrade strategy, as changes will be inevitable.
That being said, the OpenJDK+CLDR model is incorrect for Irish timekeeping and it really should get fixed at some point. Fractional seconds are a similar sort of thing, though here CLDR has made it clear that they don't care about timestamps before 1990, so this issue should not affect CLDR (unless North Korea starts using a fractional-second UTC offset :-) and only a trivial change to OpenJDK should be needed.
I still fail to see why you think this is the case. With the current TZDB, in CLDR and clients that use it, for English: - the time in July in Ireland is called "Irish Standard Time" (with abbreviation IST in en-IE) - the time in December in Ireland is called "Greenwich Mean Time" (with abbreviation GMT) What exactly is incorrect about this? Mark On Fri, Feb 9, 2018 at 11:36 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 02/06/2018 08:13 AM, Stephen Colebourne wrote:
it was never appropriate to merge the time-zones of multiple different countries (backzone being the result).
- the change caused LMT values to be lost
Those LMT values were not significant and their loss was no real loss. The only significant effect that I recall was on test suites, and test suites should not be forcing tzdb to continue to promote invented data.
- downstream consumers had to change logic wrt the meaning of backzone
Downstream consumers don't have worry about backzone. Mostly, they should just not use backzone, as it is outside the scope of tzdb proper and contains data that is not installed by default.
- it was culturally insensitive to not provide a primary Zone entry
for some countries
tzdb focuses on timekeeping practices. We should spend as few of our limited resources as possible to worry about political or cultural sensitivities that have nothing to do with timekeeping proper. Although we cannot exclude politics entirely, we should strive to not complicate the database merely to make political partisans happy, a task that would be never-ending.
2) Removal of textual short zone names.
While these names may well have been invented in some cases, the had often become de facto standards
The few invented abbreviations that became common parlance were kept. The remaining abbreviations lacked sufficient practical justification for a database where the goal is to describe timekeeping practice, not prescribe it.
- downstream consumers had to change logic to handle numeric-style
identifiers
Applications like OpenJDK+CLDR that want abbreviations and full names for every time zone needed to maintain their own databases of inventions anyway. For tzdb-style abbreviations, numeric identifiers are more accurate and less error-prone than invented ones, and have been part of the POSIX standard since 2001.
The main archive format was changed from the well-known and widely
supported gz to the niche lz format.
This has not affected downstream consumers, which can continue to use gzip format as before. Support for lzip is easily and freely available on modern platforms, including MS-Windows. Microsoft itself didn't support gzip back in the day, but that didn't mean we shouldn't have used gzip back then.
4) Negative SAVE values ...
- downstream consumers broke
The main downstream consumer that broke was OpenJDK+CLDR. The problem was soon rectified, and because OpenJDK+CLDR is an important enough consumer we now have a way in the development version to generate a form of the tzdata source that does not use negative DST offsets. That being said, the OpenJDK+CLDR model is incorrect for Irish timekeeping and it really should get fixed at some point. Fractional seconds are a similar sort of thing, though here CLDR has made it clear that they don't care about timestamps before 1990, so this issue should not affect CLDR (unless North Korea starts using a fractional-second UTC offset :-) and only a trivial change to OpenJDK should be needed.
Not one of these changes has added value to the project.
Even if there was no value to you, there is some value to record civil timekeeping more accurately. Different consumers have different needs in this area.
More importantly, there needs to be a better way for tzdb+OpenJDK+CLDR to accommodate future changes, as there inevitably will be. Of course we should not change things just for the purpose of changing. Conversely, it would not be healthy to have a software system that can never be changed and can never be improved. We should have a reasonable upgrade strategy, as changes will be inevitable.
Date: Sun, 11 Feb 2018 07:18:24 +0100 From: =?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?= <mark@macchiato.com> Message-ID: <CAJ2xs_H5OHTpqewiSSKm8YjLU1oyY_7dH1iwQxCHNEV3qWwDSA@mail.gmail.com> | What exactly is incorrect about this? When it is standard time (ie: July in Eire as you noted) tm_isdst should be 0. When it is the alternate time (ie: December in Eire) tm_isdst should be 1. Is that what you are currently seeing? If not, it is incorrect. kre
Why does that make any difference to a user? "Standard" vs "Daylight" (in English) is a naming issue. If Ireland wanted to call *neither* one of them "Standard Time" — for example, "Summer Time" vs "Winter Time", or whatever they want ("Chris O’Dowd Time" and "Dawn O'Porter Time") — why do we care? Why do people think that the name has to be aligned with that flag, because it obviously isn't in many languages/countries that don't use a term like "Standard" in the name at all. Mark On Sun, Feb 11, 2018 at 8:51 AM, Robert Elz <kre@munnari.oz.au> wrote:
Date: Sun, 11 Feb 2018 07:18:24 +0100 From: =?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?= <mark@macchiato.com> Message-ID: <CAJ2xs_H5OHTpqewiSSKm8YjLU1oyY_ 7dH1iwQxCHNEV3qWwDSA@mail.gmail.com>
| What exactly is incorrect about this?
When it is standard time (ie: July in Eire as you noted) tm_isdst should be 0. When it is the alternate time (ie: December in Eire) tm_isdst should be 1. Is that what you are currently seeing? If not, it is incorrect.
kre
Date: Sun, 11 Feb 2018 10:36:57 +0100 From: =?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?= <mark@macchiato.com> Message-ID: <CAJ2xs_Gjg4ioTx=DG-4xYBfrTnNhUiNLkb2CR=8ATbPT88z2FA@mail.gmail.com> | Why does that make any difference to a user? Depends upon the user, and what they are doing. Consider a user with an app in which the user can enter a date & time for some purpose (calendaring, or whatever). Suppose the user happens to enter the time during the period when the clocks have just switched backwards (the period of ambiguity) so the app, being a well written (and posixified) app, asks the user whether "standard time" or "alternate time" was intended. The user, in Eire, wants "Irish Standard Time" so they reply "standard" (as would anyone sane). The app then sets tm_isdst to 0 and re-does the mktime() which (as things are now) will generate the "GMT" UTC equivalent time, instead of the "IST" version, exactly the opposite of what the user intended. It does matter. | Why do people think that the name has to be aligned with that flag, The name obviously doesn't (in Eire, it could be in Gaellic) - but the concepts need to be applied correctly. The value of tm_isdst from localtime() should be simply regarded as noise, it is of no value whatever. But the uses of tm_isdst (badly named as the field is for the purpose) in mktime() are both valid, and useful, and for that it needs to work correctly. kre
“...whether "standard time" or "alternate time" was intended.” is simply a bad UI. The user may have no notion of what that "standard" means, if times in their language are called the equivalent of "Summer time" and "Winter time". And "Summer time" may actually be more of the year, and thus more "standard". Your phrase "(as would anyone sane)" would imply that all of those users are insane, which seems just a tad far-fetched. The right question to ask is to just use the names that are used: ... whether "Irish Standard Time" or "Greenwich Mean Time" was intended. Mark On Sun, Feb 11, 2018 at 11:20 AM, Robert Elz <kre@munnari.oz.au> wrote:
Date: Sun, 11 Feb 2018 10:36:57 +0100 From: =?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?= <mark@macchiato.com> Message-ID: <CAJ2xs_Gjg4ioTx=DG-4xYBfrTnNhUiNLkb2CR=8ATbPT88z2 FA@mail.gmail.com>
| Why does that make any difference to a user?
Depends upon the user, and what they are doing.
Consider a user with an app in which the user can enter a date & time for some purpose (calendaring, or whatever). Suppose the user happens to enter the time during the period when the clocks have just switched backwards (the period of ambiguity) so the app, being a well written (and posixified) app, asks the user whether "standard time" or "alternate time" was intended. The user, in Eire, wants "Irish Standard Time" so they reply "standard" (as would anyone sane). The app then sets tm_isdst to 0 and re-does the mktime() which (as things are now) will generate the "GMT" UTC equivalent time, instead of the "IST" version, exactly the opposite of what the user intended. It does matter.
| Why do people think that the name has to be aligned with that flag,
The name obviously doesn't (in Eire, it could be in Gaellic) - but the concepts need to be applied correctly.
The value of tm_isdst from localtime() should be simply regarded as noise, it is of no value whatever. But the uses of tm_isdst (badly named as the field is for the purpose) in mktime() are both valid, and useful, and for that it needs to work correctly.
kre
participants (10)
-
Andreas Stieger -
Bryan Smith -
Karel Volný -
Mark Davis ☕️ -
Paul Eggert -
Paul G -
Robert Elz -
Steffen Nurpmeso -
Stephen Colebourne -
Steve Allen