Use of <> delimiters in TZ string is not documented
The Asia/Almaty tzfile generated from recent Github tzdata snapshot contains the following TZ string at the end of the file $ git describe 2016f-7-ge0a7616 $ strings etc/zoneinfo/Asia/Almaty | tail -1 <+06>-6 This format is not documented in newtzset.3: When TZ is used directly as a specification of the time conversion information, it must have the following syntax (spaces inserted for clarity): stdoffset[dst[offset][,rule]] Where: std and dst Three or more bytes that are the designation for the standard (std) or summer (dst) time zone. Only std is required; if dst is missing, then summer time does not apply in this locale. Upper- and lowercase letters are explicitly allowed. Any characters except a leading colon (:), digits, comma (,), ASCII minus (-), ASCII plus (+), and NUL bytes are allowed.
On Aug 19, 2016, at 2:49 PM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
The Asia/Almaty tzfile generated from recent Github tzdata snapshot contains the following TZ string at the end of the file
$ git describe 2016f-7-ge0a7616 $ strings etc/zoneinfo/Asia/Almaty | tail -1 <+06>-6
But why would you expect "strings" to produce useful output for a binary data file? paul
On Fri, Aug 19, 2016 at 3:32 PM, <Paul_Koning@dell.com> wrote:
$ strings etc/zoneinfo/Asia/Almaty | tail -1 <+06>-6
But why would you expect "strings" to produce useful output for a binary data file?
That was just the easiest way to extract the TZ string. If you prefer hexdump, the following shows that the file ends with "\n<+06>-6\n": $ hexdump -C etc/zoneinfo/Asia/Almaty | tail -3 000003f0 01 01 01 01 00 00 00 00 00 00 00 00 00 00 0a 3c |...............<| 00000400 2b 30 36 3e 2d 36 0a |+06>-6.| 00000407
Thanks for catching that. I installed the attached patch into the experimental version on Github.
participants (3)
-
Alexander Belopolsky -
Paul Eggert -
Paul_Koning@dell.com