[tz] TZDB use cases

[Jürgen Appel]

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 at dfm.dk
VAT: DK-29217939