On 10.07.2017 20:19, Dave Rolsky wrote: > While you could in theory write code that would be correct for all past > datetimes, the future doesn't work the same way. As Eric noted, time > zones are political. I have seen DST transitions altered with mere days > (or less!) notice given. This means that anything you determine about > the future could be wrong. >
Of course, you are right. I should have mentioned the policy I'd like to follow (regarding my application, this partly has to do with liability in a legal sense): If the application misbehaves although correct time zone data is available at that moment, I'll have problems, and I have to avoid that under all circumstances. But if the application misbehaves because there is no correct time zone data available at that moment, I won't get into trouble. No reasonable person can expect that applications doing calculations on local dates and times behave correctly if a time zone / DST change is announced just a day before it actually happens. As far as i know, it is consensus in most legal systems that it is perfectly acceptable to use the time zone data which is currently available for your O/S for time calculations (provided that you update the O/S regularly using the appropriate mechanism). So I am not interested in the pathological cases or "the future", but I have to make sure that my application does not misbehave when a certain date-time will occur twice *and* the current time zone data already has this information. > If you're trying to avoid these, the best advice I could give would be > to avoid the 12am-4am window, which AFAIK is when most (all?) > transitions have occurred historically. I have got the same impression. But on the other hand, we can't be sure, and (according to my naive understanding) it's all in DateTime already: As the documentation tells us, DateTime always chooses the later time when calculating with ambiguous times, and if you subtract an hour from the later (ambiguous) time, you'll get the same time, but the earlier one (provided the clock is turned back by an hour when switching back). It couldn't do that if it didn't know that the time is ambiguous, could it? So, since DateTime obviously knows whether a date-time is ambiguous or not (according to the time zone database currently in place), I'd like to ask if there really is no way to implement a method that lets us query that information. Thank you very much, Binarus
