Explicitly set $ENV{TZ} in three test files.

[jkeenan]

As per usage in t/plugins/nextrelease.t.

When testing Build::Zilla in a FreeBSD-11 virtual machine, failures in
three test files were encountered. In each case, the failure occurred
when '$tzil->build;' was called in a block where the file being
processed contained non-ASCII text. In each case, an exception was
thrown whose text begins: "Cannot determine local time zone". This
message is believed to come from DateTime::TimeZone::Local.
(https://grep.metacpan.org/search?qci=&q=Cannot%20determine%20local%20time%20zone&qft=&qd=DateTime-TimeZone&f=lib%2FDateTime%2FTimeZone%2FLocal.pm)

For: #586

[ap]

I get the same DateTime::TimeZone::Local exception with TZ set to America/New_York. Setting it to Etc/GMT or Etc/UTC works for me.

[rjbs]

I am happy to apply something but this feels a bit "kick it until it works."

Perhaps a better change will be to make all DZ tests set TZ unless DateTime is able to detect the time correctly. Thoughts?

[jkeenan]

I am happy to apply something but this feels a bit "kick it until it works."

Perhaps a better change will be to make all DZ tests set TZ unless DateTime is able to detect the time correctly. Thoughts?

I have never looked into the code in the Dist::Zilla test suite, but I suspect the number of files in that suite is large -- which implies changes in more than just 3 files.

Also, how would you determine that DateTime is unable to detect the time correctly?

Thank you very much.
Jim Keenan

[karenetheridge]

I have never looked into the code in the Dist::Zilla test suite, but I suspect the number of files in that suite is large -- which implies changes in more than just 3 files.

Not if it was done in Dist::Zilla::Tester.

[ap]

Thoughts?

Sounds reasonable.

[rjbs]

@ap Do you still see this problem in the wild? Jim says he doesn't on his VM. If so, does #649 address it?

[ap]

I can no longer reproduce this problem just by attempting to install Dist::Zilla. Not sure why. But I verified the patch anyway (see the PR for details) because recent DateTime::TimeZone versions say you should be doing this regardless.

[rjbs]

Should've been fixed in v6.015