Version 2.14 t/04local.t fails under macOS 10.13 High Sierra

[trwyant]

The relevant portion of the test output is:

t/04local.t ................. 1/? 
#   Failed test 'copy of zoneinfo file at /etc/localtime'
#   at t/04local.t line 414.
#          got: 'Cannot determine local time zone
# '
#     expected: undef
Can't call method "name" on an undefined value at t/04local.t line 416.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 2 just after 232.
t/04local.t ................. Dubious, test returned 2 (wstat 512, 0x200)
Failed 1/232 subtests 

This test failure is because

DateTime::TimeZone::Local->TimeZone()

returns undef. This appears to be because of the conditions under which the test is done, and not to affect the module in use.

What appears to be happening is that the test makes a copy of the system's Asia/Kolkata file as localtime in a temporary directory, then tells DateTime::TimeZone that that temporary directory is /etc/. Because this is a real file, the DateTime::TimeZone::Local::Unix->FromEtcLocaltime() must traverse /usr/share/zoneinfo/ to figure out which zone it corresponds to. But under macOS 13 (as they spell it these days) /usr/share/zoneinfo is a symbolic link, not a directory. File::Find does not follow symbolic links by default, so the search fails. The same thing does not happen in use because under macOS these days /etc/localtime is a symbolic link, so the search is not employed.

I am preparing a pull request to address this. The proposed solution is to resolve /usr/share/zoneinfo in DateTime::TimeZone::Local::Unix->_FindMatchingZoneinfoFile() rather than telling File::Find to do it, to avoid potential problems with the latter.

[trwyant]

Pull request #23 has been submitted to address this.

[autarch]

Release in v2.15