Unix systems without /etc/localtime

[eserte]

On a CentOS 6 system without /etc/localtime or something else configured I would expect that DateTime::TimeZone::Local returns "UTC" as the time zone, like system's date:

$ date
Sat Jun 24 11:42:12 UTC 2017

However the output is:

$ perl5.24.1 -MDateTime::TimeZone::Local -e 'warn DateTime::TimeZone::Local->TimeZone()'
Cannot determine local time zone

I think as the last fallback the module can simply return "UTC". I checked other systems (Debian jessie, Debian stretch, Ubuntu 16.04, CentOS 7, FreeBSD 10.3) --- on all these systems date outputs UTC if /etc/localtime is missing.

[autarch]

On first glance, this seems relatively sane and its certainly easy to change and document. My one concern is that the existing behavior has been there for so long that someone might be relying on it.

OTOH, I regularly get bug reports and complaints about this.

On yet another hand, I suspect that in many cases there is a local time zone that this module can't detect. If, for example, your /etc/localtime is a copy of a zoneinfo file from a previous version of the Olson DB than is currently in /usr/share/zoneinfo, then DT::TZ will fail to match the files, even though you do have a local time zone.

Now, having a system with /etc/localtime with an old file and no /etc/timezone is really broken, but it does happen. And all the C-level stuff just works with the outdated /etc/localtime file. Returning UTC in this particular case might be more wrong than just dying.

[chris-morgan]

On my Ubuntu 17.04 on WSL system, /etc/localtime exists but is not a symlink; so although date knows my timezone, this is unable to determine my timezone.

It’s worth noting that /etc/localtime doesn’t actually match any standard timezone and it has the weird name “STD” which is defined properly as GMT+1000, but it’s not actually Australia/Melbourne which is the time zone I am in. I presume that there is something that keeps it in sync with the Windows side, though I doubt this is anything special to WSL. (I dunno, maybe it pretends it’s a hardware clock that knows what it’s doing? Is there such a thing? How do virtualisation platforms do it?)

As it stands, this is breaking things like the Dist::Zilla tests for me. My workaround was to set the environment variable TZ=Australia/Melbourne.

[theory]

Just got a round of cpantesters failures due to this issue. A couple examples (including some from @eserte):

• http://www.cpantesters.org/cpan/report/ed458488-1aca-11ed-b5dd-e77c2cbfd570
• http://www.cpantesters.org/cpan/report/e7c550e2-1aca-11ed-b5dd-e77c2cbfd570
• http://www.cpantesters.org/cpan/report/f2c84f1c-1aca-11ed-b5dd-e77c2cbfd570

I like that it gets tested in different time zones, so I wouldn't want to globally set TZ for all the tests. Is there something else I can put in my tests to get it to fall back to UTC if it can't determine the zone?

[autarch]

One thing I would recommend is not trying to use the user's local time zone in tests for distros that aren't DateTime-TimeZone. If you want to test stuff in different time zones, you could run the tests in a loop with different explicit time zone names.