On 11.07.2017 15:53, Zefram wrote: > Binarus wrote: >> As the documentation tells us, DateTime always chooses the later time >> when calculating with ambiguous times, > > This logic is actually in DateTime::TimeZone, where DateTime invokes > it via the ->offset_for_local_datetime method. The internal logic > is able to walk the sequence of observances, and when it finds a > matching observance it looks ahead to the next one to check specially > for ambiguity. It returns the later span if there's an ambiguity due > specifically to a change from DST to non-DST; it doesn't have guaranteed > behaviour in any other ambiguity scenario. DT:TZ doesn't document this > feature, and doesn't offer any other form of ambiguity detection in its > API (though of course it would be possible to add some).
Now I know why I didn't find according documentation. At least I was not completely wrong in believing that its all in there (although I suspected the wrong module). So is there any change to add an according API function to DT:TZ? > >> 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). > > You can't rely on offset changes, even specifically ones for DST, being of > an hour. Australia/Lord_Howe (Lord Howe Island) does a regular half-hour > DST jump. That was the reason why I have mentioned the weird preconditions in my first post. Another thing is that I eventually have to re-think the behavior of my application. In some of your posts, you indirectly have mentioned that there might be other reasons for ambiguous times than switching from DST to standard time, and of course, you are right. While my application will not be concerned by leap seconds (the application actually could do its thing when the respective moment is passed the first time, and ignore the second occurrence), it will be concerned when the time is turned back by at least 15 minutes, whether or not this happens due to DST switching or permanently because some dictator has gone nuts. In that case, the application had to do its thing upon the first occurrence of the respective time as well as upon the second occurrence. That means that the API which I would like DT::xx to provide would have to tell me if a certain arbitrary date-time will occur twice *whether or not* this will happen due to DST switching. I see that this is difficult to implement. I have to think about the situation and will try to find a solution at the application level. Thank you very much, Binarus
