On 2023-03-09 10:28, Steffen Nurpmeso wrote:
Brian Inglis wrote: |On 2023-03-08 07:50, Ken Murchison wrote: |> Attached is the diff between my working copy and -06. Comments and \ |> suggested |> text welcome. ... |Suggest using alternative rather than Daylight Savings Time as under \ |current |POSIX Base Definitions 8.3 Other Environment Variables TZ: | |https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html\ |#tag_08_03 | |"std and dst |Indicate no less than three, nor more than {TZNAME_MAX}, bytes that \ |are the |designation for the standard (std) or the alternative (dst -such as \ |Daylight |Savings Time) timezone. Only std is required; if dst is missing, then the |alternative time does not apply in this locale."...
I _think_ this is objected by kre and fine-tuning is on the way? (I am not really looking into this issue. I never dealt with these strings, but only ever used identifiers.)
POSIX is kre et al and this wording is already in use, and I do not remember seeing any edits to this in reports. The RFC addressed is IANA/IETF by the poster, including PE and ADO, so I suggest the wording and usage be aligned for accuracy and clarity. I would also be nice if TZ abbreviations and TZ or zone identifiers were used to describe what are sometimes both confusingly called TZ names. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry