On 01/02/2023 16:38, Tim Cross wrote:
This, combined with the reduced readability of such
time stamps and increased possibility of user confusion leads me to
question if allowing time stamps with both offset and time zone together
in the one time stamp is worthwhile.
Readability should not suffer if time offset is optional. It may be
omitted for non-ambiguous local time. Time offset may even improve
readability if you are looking at a timestamp with time zone unknown to you.
Sterling posted the following links (originating from the same group):
https://tc39.es/proposal-temporal/docs/ambiguity.html
https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
What I do not like is that disambiguation is option of conversion, not
of timestamp.
For instance, it does not address:
* Future time given as a local time in some specified time zone,
where changes to the definition of that time zone (e.g., a
political decision to enact or rescind daylight saving time)
affect the instant in time corresponding with the timestamp.
In this sense I like Python's approach with fold=1 or fold=2 despite in
general JavaScript Temporal proposal looks more flexible.
https://www.python.org/dev/peps/pep-0495/
