[theoriginaldave]

There is not always an unambiguous conversion from one TZ to another.

DST will always give you an ambiguous localized time. If you take input in local time, and it's in the repeating DST window (01:00<=t<02:00 for spring in USA).

Don't get me started on start of day or start of week in multi-TZ /culture environments. If you think times are bad, look at calendars.

[deathanatos]

> DST will always give you an ambiguous localized time. If you take input in local time, and it's in the repeating DST window (01:00<=t<02:00 for spring in USA).

No, it won't, and I was explicit about this in the comment you're replying to: the DST flag is part of your input time.

If you don't know the DST flag's value, you don't have a timestamp.

[nerdbert]

But don't you have 01.00 - 02.00 EST and then 01.00 - 02.00 EDT?

[theoriginaldave]

Yes, but for user input for times they normally don't include offset. So if I have a regularly scheduled event at 01:30 on February 29 should it happen at 30 min before 2:00am (2:00am only happens once or 31 min after the first 12:59 am. I can choose one or the other (or both)