Comparison takes long on dates over 2036

[houseabsolute]

Comparison takes long on dates over 2036

[abeverley]

Is there any mileage in doing some sort of "shortcut" before the timezone is added/calculated? E.g. if the day/month/year are off by so much that the timezone is irrelevant. Even something simple like if the years are different by more than 2 would work for our use case. Thanks.

[autarch]

@abeverley - yes, that sort of fix could work. I think just checking if the year diff is >1 would be sufficient.

[autarch]

@markov2 I'm not sure how one would decide when to start ignoring time zones. This really is something that users of the library are in a much better position to do than me as the library author.

[autarch]

This actually isn't happening in DateTime.pm, it's because of how DateTime::TimeZone works. If the time zone has DST rules, then we need to calculate all the DST transitions until the timestamp for the DT.

This particular case is triggering the issue because when you compare a DT with a floating TZ to one without, it sets the DT with the floating TZ to the same TZ as the DT we're comparing against. Otherwise there's no way to compare the two.

It doesn't really make sense to use a time zone more than a few years in the future, as time zone rules change regularly. It definitely doesn't make sense to use them for dates that are decades away.

There is a warning if you try to create a far future DT with a non-UTC or floating TZ. I think it'd make sense to also warn in other cases that trigger this behavior, like the comparison case here.

[markov2]

Do you really need to calculate time-zones when the years differ?

[autarch]

Do you really need to calculate time-zones when the years differ?

Of course. If one TZ is at +12 and the other at -12 then you could easily have a case where the years differ but the one with a lower year is actually later in UTC.

[arodland]

But then again, not if the years differ by more than 1. And indeed probably not if the ymd-part differs by 3 or more days :)

[markov2]

But can you explain why, in above script $dt1 < $dt2 takes 7 seconds on my system, but $dt1->epoch < $dt2->epoch less than one millisecond?

Wouldn't it simplify the code a lot when _compare() would simple call epoch() ?

[autarch]

But can you explain why, in above script $dt1 < $dt2 takes 7 seconds on my system, but $dt1->epoch < $dt2->epoch less than one millisecond?

I already did. It's because the DT in the floating time zone is converted to the time zone of the other DT, so it's equivalent to calling $dt1->clone->set_time_zone('Europe/London')->epoch < $dt2->epoch.

[markov2]

Certainly with an uncertain future of DST, wouldn't it be safe to simply ignore their existence for years to come? At least: until now, all DST effects have neutralized after the end of each year: no nett effect... it is only required to calculate the last year. Not all intermediate years.

(In our application, people can describe events will happen in the future (years). We do not want that to be inconveniently slow)