[tz] Fwd: New Version Notification for draft-murchison-rfc8536bis-06.txt

Brian Inglis Brian.Inglis at Shaw.ca
Thu Mar 9 19:54:34 UTC 2023

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

More information about the tz mailing list