Bug #79698 [Opn->Csd]: timelib mishandles future timestamps (triggered by 'zic -b slim')
| From: | derick@php.net | Date: | Tue, 06 Apr 2021 19:56:27 +0000 |
| Subject: | Bug #79698 [Opn->Csd]: timelib mishandles future timestamps (triggered by 'zic -b slim') | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-233266@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=79698&edit=1
ID: 79698
Updated by: derick@php.net
Reported by: eggert at cs dot ucla dot edu
Summary: timelib mishandles future timestamps (triggered by
'zic -b slim')
-Status: Open
+Status: Closed
Type: Bug
Package: Date/time related
Operating System: any
PHP Version: 7.4.7
-Assigned To:
+Assigned To: derick
Block user comment: N
Private report: N
New Comment:
The fix for this bug has been committed.
If you are still experiencing this bug, try to check out latest source from https://github.com/php/php-src and re-test.
Thank you for the report, and for helping us make PHP better.
Fixed for PHP 8.1.
Previous Comments:
------------------------------------------------------------------------
[2020-06-13 20:03:03] nikic@php.net
Can you please report this issue upstream at https://github.com/derickr/timelib/issues?
------------------------------------------------------------------------
[2020-06-13 20:00:27] eggert at cs dot ucla dot edu
Description:
------------
Since tzdb 2019b, the 'zic' command has had a '-b slim' option that generates
smaller-but-equivalent TZif files, intended to save memory/cache/whatever. These files conform to
the TZif format specified in Internet RFC 8536 and are supported by tzcode, glibc, etc. and '-b
slim' is intended to be the default in future tzdb releases. However, some current PHP timelib
test cases fail with slim TZif files.
This mishandling seems to occur because timelib gets confused about timestamps after the last
explicit transition in a TZif file. For example, 'zic -b slim' generates a TZif file
Europe/Amsterdam where the last explicit transition is on 1996-03-31 and transitions thereafter are
deduced from the "CET-1CEST,M3.5.0,M10.5.0/3" string embedded at the end of the TZif file.
The test case decoding 2008-03-30 01:00:00 fails, I expect because this timestamp is after the last
explicit transition.
If my guess is right, timelib also mishandles timestamps past the last explicit transition even in
traditional "fat" TZif files. For example, since the last transition in a traditional
Europe/Amsterdam file is 2037-10-25 I would expect timelib to mishandle some timestamps after that.
As the '-b slim' option becomes more popular this problem will affect PHP even for past
and current timestamps, so the bug needs to be fixed sooner than 2038.
Test script:
---------------
#!/bin/sh
# This assumes a typical GNU/Linux host.
wget https://data.iana.org/time-zones/releases/tzdb-2020a.tar.lz
tar xf tzdb-2020a.tar.lz
cd tzdb-2020a
make
make ZFLAGS='-b slim' posix_only # This needs root privileges!
cd ..
git clone https://github.com/derickr/timelib.git
cd timelib
make test
Expected result:
----------------
I expect all tests in 'make test' to succeed.
Actual result:
--------------
Most tests succeed, but I see the following failures:
transition.render
FAIL | 2008-03-30 02:00:00 CEST Europe/Amsterdam | 1206835200 (Europe/Amsterdam)
EXP = 2008-03-30 01:00:00 CET Europe/Amsterdam
FAIL | 2008-03-30 02:59:59 CEST Europe/Amsterdam | 1206838799 (Europe/Amsterdam)
EXP = 2008-03-30 01:59:59 CET Europe/Amsterdam
...
render.render
...
FAIL | 2005-10-30 03:00:00 CEST Europe/Oslo | 1130634000 (Europe/Oslo)
EXP = 2005-10-30 02:00:00 CET Europe/Oslo
...
FAIL | 2005-10-30 03:00:00 CEST Europe/Amsterdam | 1130634000 (Europe/Amsterdam)
EXP = 2005-10-30 02:00:00 CET Europe/Amsterdam
FAIL | 2005-10-30 04:00:00 CEST Europe/Amsterdam | 1130637600 (Europe/Amsterdam)
EXP = 2005-10-30 03:00:00 CET Europe/Amsterdam
FAIL | 2005-10-30 05:00:00 CEST Europe/Amsterdam | 1130641200 (Europe/Amsterdam)
EXP = 2005-10-30 04:00:00 CET Europe/Amsterdam
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=79698&edit=1