search

houseabsolute / DateTime-TimeZone

Time zone object base class and factory
https://metacpan.org/release/DateTime-TimeZone/
Other
9 stars 25 forks source link

issue 22: Handle /etc/share/zoneinfo when a symbolic link #23

Closed trwyant closed 6 years ago

trwyant commented 6 years ago

This becomes a problem when /etc/localtime is a copy, rather than a symbolic link, and DateTime::TimeZone::Local::Unix must use File::Find to traverse all the zone files to figure out which one was copied.

File::Find::find() does not follow symbolic links by default, though things like -d do. So we resolve the link if necessary before calling find().

The only instance known to me that triggers this is testing under macOS 13 High Sierra. Actually running under that OS is fine, since /etc/localtime is a symbolic link. But when testing, a copy is used.

preaction commented 6 years ago

This makes sense to me. And the problem you're avoiding by not using follow => 1 or the other File::Find options to follow symlinks is the additional performance cost that would incur for that File::Find operation, correct?

Could even more pathological organizations of symlinks in the zoneinfo database cause problems? Would it be of any benefit to err on the side of correctness and follow all symlinks wherever they lead?

Even so, I'm okay with this patch: It clearly identifies the problem, explains the solution, and is noticeable enough that if there are further symlink problems down the line it can be adjusted.

autarch commented 6 years ago

Merged from the CLI. Thanks!