Canada/East-Saskatchewan
Hi, I saw that the PHP build with the new timezone database (2017.3) failed due to Canada/East-Saskatchewan suddenly being gone. What's up with that? https://travis-ci.org/php/php-src/jobs/291636544#L1280 cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php twitter: @derickr and @xdebug
Derick Rethans wrote:
I saw that the PHP build with the new timezone database (2017.3) failed due to Canada/East-Saskatchewan suddenly being gone. What's up with that?
As explained in the NEWS file: Remove Canada/East-Saskatchewan from the 'backward' file, as it exceeded the 14-character limit and was an unused misnomer anyway. -zefram
On 10/23/2017 01:01 PM, Zefram wrote:
Derick Rethans wrote:
I saw that the PHP build with the new timezone database (2017.3) failed due to Canada/East-Saskatchewan suddenly being gone. What's up with that? As explained in the NEWS file:
Remove Canada/East-Saskatchewan from the 'backward' file, as it exceeded the 14-character limit and was an unused misnomer anyway.
Yes, it looks like php-src/ext/date/lib/timezonedb.h was updated to 2017c without making the corresponding changes to php-src/ext/date/lib/timezonemap.h. The PHP build needs those two files to be consistent with each other. What program generates those two files, by the way? I'd like to mention it in tz-link.htm.
On Mon, 23 Oct 2017, Paul Eggert wrote:
On 10/23/2017 01:01 PM, Zefram wrote:
Derick Rethans wrote:
I saw that the PHP build with the new timezone database (2017.3) failed due to Canada/East-Saskatchewan suddenly being gone. What's up with that? As explained in the NEWS file:
Remove Canada/East-Saskatchewan from the 'backward' file, as it exceeded the 14-character limit and was an unused misnomer anyway.
Yes, it looks like php-src/ext/date/lib/timezonedb.h was updated to 2017c without making the corresponding changes to php-src/ext/date/lib/timezonemap.h. The PHP build needs those two files to be consistent with each other.
You're right that timezonemap.h needs updating, but it has nothing to do with Canada/East-Saskatchewan missing and failing the test. It's simply a data point that is now gone.
What program generates those two files, by the way? I'd like to mention it in tz-link.htm.
It's part of https://github.com/derickr/timelib, which powers the date/timezone support for PHP, HHVM and MongoDB. Typically you run "make clean && make cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php twitter: @derickr and @xdebug
On 10/24/2017 02:51 AM, Derick Rethans wrote:
You're right that timezonemap.h needs updating, but it has nothing to do with Canada/East-Saskatchewan missing and failing the test. It's simply a data point that is now gone.
I assumed that timezonemap.h was the source for the tests, in that the test runs through each of its entries and makes sure that they work. So if you update timezonemap.h to match the current tzdb then the tests should succeed again. If I'm wrong and something else is testing Canada/East-Saskatchewan, then that other thing needs to be updated. As far as I know, Canada/East-Saskatchewan has not been in production use for many years; it's used only by programs that test tzdb exhaustively.
What program generates those two files, by the way? I'd like to mention it in tz-link.htm. It's part ofhttps://github.com/derickr/timelib, which powers the date/timezone support for PHP, HHVM and MongoDB.
Thanks for the info; I installed the attached patch to tz-link.htm to point to it.
So, how is it that we're ok with deleting Canada/East-Saskatchewan, but somehow we have to leave US/Pacific-New? We could delete a whole file from the repo... What ARE the rules for when a name is ok to be deleted entirely? AFAIK, this is the first time in a long while that we didn't just move it to the backward file. -Matt -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Paul Eggert Sent: Tuesday, October 24, 2017 10:47 AM To: Derick Rethans <derick@derickrethans.nl> Cc: Time Zone Mailing List <tz@iana.org> Subject: Re: [tz] Canada/East-Saskatchewan On 10/24/2017 02:51 AM, Derick Rethans wrote:
You're right that timezonemap.h needs updating, but it has nothing to do with Canada/East-Saskatchewan missing and failing the test. It's simply a data point that is now gone.
I assumed that timezonemap.h was the source for the tests, in that the test runs through each of its entries and makes sure that they work. So if you update timezonemap.h to match the current tzdb then the tests should succeed again. If I'm wrong and something else is testing Canada/East-Saskatchewan, then that other thing needs to be updated. As far as I know, Canada/East-Saskatchewan has not been in production use for many years; it's used only by programs that test tzdb exhaustively.
What program generates those two files, by the way? I'd like to mention it in tz-link.htm. It's part ofhttps://github.com/derickr/timelib, which powers the date/timezone support for PHP, HHVM and MongoDB.
Thanks for the info; I installed the attached patch to tz-link.htm to point to it.
On 10/25/2017 11:32 AM, Matt Johnson (AZURE) wrote:
So, how is it that we're ok with deleting Canada/East-Saskatchewan, but somehow we have to leave US/Pacific-New? We could delete a whole file from the repo...
What ARE the rules for when a name is ok to be deleted entirely? AFAIK, this is the first time in a long while that we didn't just move it to the backward file.
We deleted Canada/East-Saskatchewan because of the thread starting here: http://mm.icann.org/pipermail/tz/2017-July/025190.html The basic idea was that overall the (trivial) cost of keeping Canada/East-Saskatchewan around exceeded the (even more trivial) benefit. I'm open to the idea that a similar argument applies to the 'pacificnew' file. If it would simplify maintenance overall to move its contents into the 'backward' file and remove the 'pacificnew' file, then we should do that.
I wrote:
I'm open to the idea that a similar argument applies to the 'pacificnew' file. If it would simplify maintenance overall to move its contents into the 'backward' file and remove the 'pacificnew' file, then we should do that.
After thinking about this some more, I believe the argument does not apply to 'pacificnew'. The only function of 'pacificnew' is to create a link US/Pacific-New that is so mistaken and confusing that it is worth keeping separate from 'backward', so that people can easily avoid installing it. Come to think of it, eventually we should remove 'pacificnew' as it causes more trouble than it is worth; see https://bugs.debian.org/815200 for an example. To help get the ball rolling, the attached proposed patch changes the default installation procedure to omit US/Pacific-New, by removing 'pacificnew' from the default BACKWARD macro in 'Makefile'.
Hello, On 11/04/2017 05:06 PM, Paul Eggert wrote:
To help get the ball rolling, the attached proposed patch changes the default installation procedure to omit US/Pacific-New, by removing 'pacificnew' from the default BACKWARD macro in 'Makefile'.
And here is the related build fix to make the 2018a distributed tarball build: https://github.com/eggert/tz/pull/21/commits/270a7f2939caadd2d1ead2e4dd4b35c... Andreas -- Andreas Stieger <astieger@suse.com> Project Manager Security SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
On Tue, 24 Oct 2017, Paul Eggert wrote:
On 10/24/2017 02:51 AM, Derick Rethans wrote:
You're right that timezonemap.h needs updating, but it has nothing to do with Canada/East-Saskatchewan missing and failing the test. It's simply a data point that is now gone.
I assumed that timezonemap.h was the source for the tests, in that the test runs through each of its entries and makes sure that they work. So if you update timezonemap.h to match the current tzdb then the tests should succeed again.
That did indeed end up being the case. I've updated timezonemap.h now: https://github.com/php/php-src/commit/8e3260376c65b762a51eee7c30ab560dadefa1...
What program generates those two files, by the way? I'd like to mention it in tz-link.htm. It's part ofhttps://github.com/derickr/timelib, which powers the date/timezone support for PHP, HHVM and MongoDB.
Thanks for the info; I installed the attached patch to tz-link.htm to point to it.
Not sure if you'd like to mention it, but timelib's other big thing is that it can parse textual descriptions of date/time strings from a large variety of formats: http://php.net/manual/en/datetime.formats.php cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php twitter: @derickr and @xdebug
participants (6)
-
Andreas Stieger -
Derick Rethans -
Derick Rethans -
Matt Johnson (AZURE) -
Paul Eggert -
Zefram