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

[Brian Inglis]

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