Paul Eggert via tz wrote in <0ae0a22c-cc42-4671-bb3c-fdc4c7ec3237@cs.ucla.edu>: |On 2026-03-06 18:08, Robert Elz via tz wrote: ... |> where indeed PT would not be usable, but we have no reason to care about |> that | |Unfortunately we do. See Internet RFC 9636 section 3.3 One more of those RFCs that should never have been written! And if standardizing a binary file format of some library, then some standardized binary format should have been used. I was asking for CBOR by then, granted for the over-the-net tz stuff that does not fly, and, of course, only as a suggestion, yaml or even (i hate it for several mostly good Unicode reasons) json or anything that is standardized and has schema support. Ie, all the same data, all the same format. The "Interoperability Considerations" is self-speaking against the binary "upward-compatible" of the introduction, and mostly everywhere the project code is used, accompanying the data, as i see it, otherwise the considerations have to be considered. Right. Btw personally i am hoping that the Go TZif reader that you link from your own homepage, that its comments form the critique i would state, especially that ~"and now we can form the actual data" is indeed Monty Pythonesque. And then you even need bug workarounds for certain implementations. I would vote for adding another variant, in a standardized container format, eventually growing out the old one, installed like /etc/localtime.X where X is accordingly. The RFC speaks about "obsolescent version-1-only readers MUST", so the RFC implies code changes are doable on even those obsolescent version-1-only readers. (Shudder.) ... |Although we could relax these restrictions in later RFCs, that's not ... Or drop those altogether. They have no value, and never had, really, in my opinion, except for possibly specifying a data schemata. Soon all readers are obsolescent, and the new RFC would have to add more paragraphs on "placeholder version XY datablocks". There is still over a decade until 64-bit time is really needed. Turn to localtime.X where X is, i am guessing, JSON. (Despair here.) (Btw, and now off-topic, i know a former member of FSF Europe who is prowd of a personal signature of Mr. Stallman, and who is in the process of developing KEKS is compact, deterministic, concise and streaming binary serialisation format. It is aimed to be lightweight in terms of CPU, memory, storage and codec implementation size usage. It supports wide range of data types, making it able to transparently replace JSON. KEKS/Schema is a schema definition format for describing data structures validation steps. etc with already implementations in C, Go, python3, tcl, if i get this right. git://git.cypherpunks.su/keks.git. Since you seem to be interested in good small things, and surrounding the FSF universe, like Diaz's lzip.) ... |something we could reasonably expect all downstream TZif readers and |producers to implement by November, so for now the restrictions do |impinge on what we can put into America/Vancouver for this issue. | |Besides, alphabetic time zone abbreviations are problematic given their |ambiguity and lack of standardization, and so I doubt whether it'd be |wise to relax the restrictions and encourage use of shorter |abbreviations like "PT" or (shudder!) "O". We have trouble enough as it |is with these things. | |I quite agree, and POSIX.1-2024 started the ball rolling on getting rid |of that garbage. Alas the job is still incomplete. (This is veering off |into a different subject of course.) Drop it altogether. There are incompatibilities, there are bugs, the number of actively developed TZif readers is not that large, as far as i know, and those which do often use languages which ship infrastructure to go JSON/X out-of-the-box, and easily. And with automatic schema you then also get *data content verification* for free, as opposed to only binary data structure. (As in, "how many readers perform really proper verification?") And with a filename with regular file extension you integrate in "the normal" mime.types approach much better, ie, RFC 9636's "When a TZif file is used in a MIME message entity, it SHOULD be indicated by one of the following media types" requires "magic" logic (aka file content inspection, as opposed to only file extension checks via eg /etc/mime.types) that many applications do not support, not even those that make use of the monstrous (imho) freedesktop.org/xdg/shared-mime-info it seems $ pkginfo -l shared-mime-info | grep -i tz usr/share/mime/application/x-tzo.xml and that one unfortunately cannot get rid of $ prt-get dependent shared-mime-info gobject-introspection $ prt-get dependent gobject-introspection glib-introspection $ prt-get dependent glib-introspection gdk-pixbuf at-spi2-core harfbuzz Sigh. Granted file(1) of NetBSD's Zoulas can $ file /usr/share/zoneinfo/Iran /usr/share/zoneinfo/Iran: timezone data (slim), version 2, no gmt time flags, no std time flags, no leap seconds, 71 transition times, 6 local time types, 28 abbreviation chars pretty impressive, but wait $ file --mime-type /usr/share/zoneinfo/Iran /usr/share/zoneinfo/Iran: application/octet-stream or what $ file --mime-encoding /usr/share/zoneinfo/Iran /usr/share/zoneinfo/Iran: binary Noone ever cared. (But even if, i for example have my own mime.types ie based on extensions, and it will prowdly support things like # built-in mimetype application/x-lzma lzma # built-in (not for sending mail) mimetype ?only-handler application/x-tar-lzma tar.lzma with the next release.) "Get rid of that garbage", yes. (RFC, not readers -- i have not really looked at their code. But code there is, sometimes quite a bit.) And tzdata.si is great. Thank you. --End of <0ae0a22c-cc42-4671-bb3c-fdc4c7ec3237@cs.ucla.edu> --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)