Dear Stephen, On Wednesday, 29 September 2021, you wrote:
In this thread I want to try and capture the *requirements* for the project from the perspective of a downstream user. Given this, we may then have a chance to analyse whether the project needs a change of rules.
Thank you very much for undertaking this effort. I believe this is an important step towards having a fruitful discussion later on on how to handle the timezone data policies.
Please note that the above is not a proposal, but an exploration of the design space. If you have any use cases I've missed feel free to write them up.
I support your suggestion to gather this data first before we delve into details of the implementation / possible changes. ==A note regarding your examples: a) Although possibly a boundary case, I'd like to add that when using location based identifiers, for past or future times, a unique conversion from local time to UTC is sometimes impossible: 2020-10-25 02:30:00 Europe/Copenhagen cannot be mapped unambiguously to UTC, whereas the reverse mapping works of course. I am not aware of any software that takes this into account. b) Additionally, there exist invalid times: 2020-03-29 02:30:00 Europe/Copenhagen is one example, and when/if negative leap seconds arise dates such as 2022-07-01 01:59:59 Europe/Copenhagen could be another one. Therefore a reasonable requirement from the downstream user side would be to convey information about such conditions ('invalid time' , 'ambiguous time', evtl. also 'unconfirmed tzdata' for times not covered in the database) Cheers, Jürgen -- Jürgen Appel Research Scientist Denmark's National Metrology Institute Dansk Fundamental Metrologi, DFM A/S (dfm.dk) Kogle Allé 5 DK-2970 Hørsholm Denmark Mobile: +45 25459049 Email: jap@dfm.dk VAT: DK-29217939