Bug #123229 for Date-Manip: Date::Manip fails to load when /etc/localtime is "Factory" timezone

Mon Oct 09 17:04:04 2017 KENTNL [...] cpan.org - Ticket created

Subject:

Date::Manip fails to load when /etc/localtime is "Factory" timezone

I'm not sure if this is in Date-Manips territory or not, but I've been working around this issue for a while and was wondering if somewhere closer to the problem is appropriate.

Upon completing a fresh stock install of Gentoo from installation media, the /etc/localtime is a copy of /usr/share/zoneinfo/Factory which I believe is built from this file : https://github.com/eggert/tz/blob/master/factory

And this file is provided by upstream for this purpose.

And /etc/timezone does not exist.

This causes Date-Manip to cease working in entirety, and causes lots of things that only try to load it to see if its installed or not to also fail.

perl -MDate::Manip -e1
ERROR: Date::Manip unable to determine Time Zone.
ERROR LOADING MODULE: Date::Manip::DM6 at <>/Date/Manip.pm line 35.
Compilation failed in require.
BEGIN failed--compilation aborted.

But its of my opinion that "hey, user hasn't configured their timezone" is not good grounds for not being able to build packages.

So I've just been working around the problem by setting TZ=UTC inside the build chain code, and deferring the "Hey, you probably should set your timezone" problem to somewhere else.

If there could be a better solution for this problem closer to where it appears, that'd be awesome :)

--
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )

Thu Oct 12 13:12:19 2017 sbeck [...] cpan.org - Correspondence added

I have some mixed feelings concerning this. On one hand, I'm asking myself "if a module cannot be loaded in a way that is usable, should it be loadable?" A great deal of Date::Manip's functionality depends on on the timezone being determined. So much so that I've got that assumption built in a lot of places. One solution would be to track down every one of those places and add an if timezone isn't determined do the right thing else do something else (probably set an error code) endif However, that assumption is made often enough that I am really adverse to doing that. Instead, I'm considering the alternate solution of using 'GMT' as the default timezone. If a timezone cannot be determined, you'll still get an error message ERROR: Date::Manip unable to determine Time Zone. Using GMT for all operations. but then continuing. That would be enough to solve your problem. However, on a secondary note, I really would like to be able to figure out the timezone. If there are ANY other methods for determining the timezone on Gentoo that are available at the time this is happening during your build, let me know and I can add them.

Thu Oct 12 13:12:20 2017 The RT System itself - Status changed from 'new' to 'open'

Thu Oct 12 13:28:49 2017 sbeck [...] cpan.org - Correspondence added

I've decided that making GMT the default timezone is safe, and very unlikely to interfere with anything (the only backward incompatible change is that where previously Date::Manip couldn't load, now it can, and will even function, but without knowing the local timezone). That seems like a pretty safe change. It'll be in the next release (due out the beginning of December).

Thu Oct 12 13:35:36 2017 KENTNL [...] cpan.org - Correspondence added

On 2017-10-13 06:12:19, SBECK wrote:
> I have some mixed feelings concerning this.
>
> On one hand, I'm asking myself "if a module cannot be loaded in a way
> that is usable, should it be loadable?" A great deal of Date::Manip's
> functionality depends on on the timezone being determined. So much so
> that I've got that assumption built in a lot of places.
>
> One solution would be to track down every one of those places and add
> an
> if timezone isn't determined
> do the right thing
> else
> do something else (probably set an error code)
> endif
>
> However, that assumption is made often enough that I am really adverse
> to doing that.
>
> Instead, I'm considering the alternate solution of using 'GMT' as the
> default timezone. If a timezone cannot be determined, you'll still
> get an error message
>
> ERROR: Date::Manip unable to determine Time Zone. Using GMT for all
> operations.
>
> but then continuing. That would be enough to solve your problem.
>
> However, on a secondary note, I really would like to be able to figure
> out the timezone. If there are ANY other methods for determining the
> timezone on Gentoo that are available at the time this is happening
> during your build, let me know and I can add them.

The tricky part is at this stage, there *is* no "timezone" other than the factory one.

And being a "You have to do everything manually" distribution, setting the timezone is a manual step documented in the install guide.

https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#Timezone

I agree that everyone *should* set this, and even if they do *half* these steps, ( eg: making the /etc/timezone file, but failing the --configure step ), then Date::Manip will function as intended ( I discovered this in testing it on a different box because borking my localtime wasn't enough on its own, I had to bork that file and nuke /etc/timezone )

So for most people Date::Manip is already doing more than enough.

Its just for whatever reason when I set up my testing chroot, I missed this step, and I didn't even *notice* it was broken for *weeks* until Date::Manip started failing when I test-installed it :)

So I've just left it as-is because I figure if I can make that mistake, somebody else can.

And with a little bit of poking, I found other people have had similar issues:

https://bugs.gentoo.org/30129#c1

But yes, I agree, "pretend its GMT" is a sensible alternative to breaking IMO, because that's the behaviour the Factory Zone does for everything else, the only discriminator being the "-" on the TZ code.

--
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )

Thu Oct 12 14:31:01 2017 sbeck [...] cpan.org - Status changed from 'open' to 'resolved'