Edit report at https://bugs.php.net/bug.php?id=66985&edit=1
ID: 66985
Comment by: theodore at phpexperts dot pro
Reported by: evert at rooftopsolutions dot nl
Summary: Some timezones are no longer valid in PHP 5.5.10
Status: Re-Opened
Type: Bug
Package: Date/time related
Operating System: Any
PHP Version: 5.5.10
Block user comment: N
Private report: N
New Comment:
This has been the biggest barrier in adopting PHP 5.5 so far. My corporation had already spent a lot
of time porting our apc_get() stuff to Memcache, and then when we released to Production,
"BOOM!"
Who would have thought it would come down to date.timezone=CST6CDT???
It's not even a Warning, it's an Exception. It was an embarrassment, and worse, I read
this bug report for over 4 months and NOTHING. I saw the Pull Request for the fix, and again,
derision for the coder who submitted it and nothing.
Know what we did? We technically *forked* PHP, applied that patch, and have been stuck on 5.5.10
ever since. Not a good state to be in.
Then, one day, a developer (me) found out this:
<?php
$d = new DateTime('now', new DateTimeZone('CST6CDT'));
echo $d->format('c') . "\n";
tsmith@aerilon ~ $ hhvm date.php
2014-07-25T15:36:13-05:00
tsmith@aerilon ~ $ php date.php
PHP Fatal error: Uncaught exception 'Exception' with message
'DateTimeZone::__construct(): Unknown or bad timezone (CST6CDT)' in
/home/tsmith/date.php:3
In the end, the corporate policy got set that we were going to aim for 100% hhvm compatibility by
December 2014 [top priority] and look at the feasibility of porting the majority of our inhouse code
to HHVM+Hack. Just because of this bug, why it was caused (sloppy deving, face it, coupled with lax
releasing standards), and its "response". Which until just a few days ago was borderline
derision at best.
This, combined with all the drama of Internals, the superstitious skipping of PHP v6 for v7, and the
entire PHP-Next vs the stupid side-patch for type casting... Let's just hope Facebook gets that
PHP language spec released before the entire language goes 5 different directions.
Zend Corp.'s share holders need to do something. Like maybe set down the hammer and give full
control of the core to, you know, the core devs? That'd be an OK start.
Previous Comments:
------------------------------------------------------------------------
[2014-07-20 00:43:59] rasmus@php.net
Hrm.. In my simple test it worked. It was zone_search() that was failing. With that hack this works
fine:
$tz = new DateTimeZone('EST5EDT');
echo $tz->getName()."\n";
$date = new DateTime('2000-01-01', $tz);
$date = $date->modify('+6 months');
echo $date->format('Y-m-d') . "\n";
But true, looking closer at it, $tz->getTranstitions() doesn't return anything.
------------------------------------------------------------------------
[2014-07-19 00:02:31] yohgaki@php.net
Note: JST (Japanese Standard Time) is used to work with older PHP also.
------------------------------------------------------------------------
[2014-07-18 16:04:17] derick@php.net
It doesn't work, there are some other bits of code that only let allow through IDs with a / in
them. I've moved this to the top of my todo list, so hopefully get to it soon.
------------------------------------------------------------------------
[2014-07-18 15:51:51] rasmus@php.net
Derick, wouldn't the easiest solution just be to add these to timezonemap.h?
As in, for EST5EDT it would be something like:
{ "edt", 1, -14400, "EST5EDT" },
{ "est", 1, -18000, "EST5EDT" },
------------------------------------------------------------------------
[2014-07-16 17:01:09] evert at rooftopsolutions dot nl
OT: Bit dissapointed that it required a comment from Rasmus for this issue to be as much as
acknowledged. Didn't ask for an immediate fix, but getting ignored really sucks.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=66985
--
Edit this bug report at https://bugs.php.net/bug.php?id=66985&edit=1