develooper Front page | perl.datetime | Postings from July 2017

Re: How to tell (in advance) if a date-time is ambiguous?

Thread Previous | Thread Next
From:
Binarus
Date:
July 12, 2017 06:32
Subject:
Re: How to tell (in advance) if a date-time is ambiguous?
Message ID:
d8b04692-4633-fab6-b156-430e60e1740b@binarus.de
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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About