The semantic issue here is that users typically say "01:45" and
it never occurs to them to even think about *which* 01:45 they mean.
So recovering that extra information is hard (it's like dealing with
byte streams where the user didn't provide details of the text
encoding used). Once we have the extra information, though, doing
conversions is just a matter of applying a set of rules.
It is slightly more complicated than that. There are locations (even in the US, I've heard)
where clocks have been moved back for reasons other than DST. I described one such
example in my earlier post . On July 1, 1990, at 2AM, the people of Ukraine celebrated
their newly acquired independence by moving their clocks back to 1AM thus living
through "1990-07-01T01:45" local time twice. This happened in the middle of summer and
daylight savings time was in effect before and after the transition, so you cannot use isdst
to disambiguate between the first and the second "01:45".
On the other hand, these rare events are not that different from more or less regular DST
transitions. You still have either a non-existent or ambiguous local times interval and
you can resolve the ambiguity by adding 1 bit of information. The only question is what
should we call the flag that will supply that information? IMO, "isdst" is a wrong name