Time::Local 2020 issue

[Raluca Farcas]

Time::Local updated some unit tests in version 1.26 to resolve this problem: https://rt.cpan.org/Public/Bug/Display.html?id=124787. The test should have failed in 2020 for previous versions. I've seen last version of Mojolicious is still using Time::Local version 1.2. And on my application this goes on failing the Time::Local unit test. Do you know about the problem? Is there a chance to update your dependencies, especially Time::Local to a version >= 1.26? Thanks in advance for the answer. 

[Dan Book]

Updating Time::Local does not fix anything by itself, it only gives you more options. Additionally, the dependency is a minimum requirement, you are free to install the newer version that does not fail its own tests. I will audit the use of Time::Local to ensure it is not falling prey to the issue.

-Dan

On Fri, Mar 6, 2020 at 5:46 AM Raluca Farcas <raluca...@gmail.com> wrote:

Time::Local updated some unit tests in version 1.26 to resolve this problem: https://rt.cpan.org/Public/Bug/Display.html?id=124787. The test should have failed in 2020 for previous versions. I've seen last version of Mojolicious is still using Time::Local version 1.2. And on my application this goes on failing the Time::Local unit test. Do you know about the problem? Is there a chance to update your dependencies, especially Time::Local to a version >= 1.26? Thanks in advance for the answer. 

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mojolicious/cc37b38e-362c-4316-90b3-1c502fe1ca33%40googlegroups.com.

[Dan Book]

Looking at the usage of timegm in Mojo::Date, it is used to parse date formats that either provide a 4 digit year or a 2 digit year which is ambiguous as to its century (RFC 850). As such I think the original timegm year parsing is actually the best option here, an alternative is to always interpret 2 digit years as being in the 1900s and use timegm_modern.

-Dan