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
July 11, 2017 09:35
Re: How to tell (in advance) if a date-time is ambiguous?
Message ID:
On 11.07.2017 01:09, Zefram wrote:
> Binarus wrote:
>> Using DateTime, is it possible to tell in advance if a certain date-time
>> which is given in a certain locale will be ambiguous due to switching
>>from DST to standard time?
> That is tricky.  I don't think our APIs provide any way to do it.
> Thinking about the facilities available a bit lower down, the way I'd
> probably approach it is to look at the list of all the offsets ever used
> in that timezone (not available through any API, but extractable from
> the tzfile).  I'd compute for each the UT time that would be represented
> by the specified local time with that offset, and then use the regular
> API to convert that UT time to the local time in the specified timezone
> (or equivalently just to look up the zone's offset for that UT time).
> Look at which local times come out matching the specified local
> time (which offsets match the candidate offset that we were trying).
> If there's more than one match, that's an ambiguous local time.  If there
> are no matches, it's a non-existent local time.

At first, thank you very much for your answer!

I see. I always thought that the tzfile only contained the offsets for
standard time (and not DST). Obviously, I have been wrong (I never had a
look into a tzfile yet because I hope that I could solve my problem
without reading it out directly).

> Something close to this can actually be done in the C time API.  You
> don't get to ask what all the zone's offsets are, but in the local->UT
> conversion you can specify whether DST is in effect.  Giving both states
> of that flag gives you two UT times, which you can then convert back
> to local to check whether they come out with the same DST flag state.
> This will work for regular DST changes, but not for offset changes that
> are unrelated to DST.

This is very interesting. Actually, I am doing more things in C than in
Perl (but on other architectures), but since I thought that DateTime was
mirroring all capabilities libc has in this respect, I did not look into
the C time API yet. I have no dislike against writing a part of the
application in C (but then will have to learn how to call C from Perl).

Again, thanks for all advice,


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About