On Mon, Jul 27, 2015 at 10:59 AM, Paul Moore firstname.lastname@example.org wrote:
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 for dealing with the event I described above.