You can clone with
HTTPS or Subversion.
Debian ticks me off.
So, a user (Joe Orton) suggested to internals@ that the system timezone be consulted if the timezone identifier was System/Localtime, which it would be by default. internals@ declined (http://thread.gmane.org/gmane.comp.php.devel/47609), and he produced a patch for Debian that was eventually included into their distribution.
> New patch (use_embedded_timezonedb.patch) allows us to default to using the system provided timezone database instead of the one bundled with PHP. Many thanks to Joe Orten from Red Hat for the patch! (closes: [#447174](http://bugs.debian.org/447174), [#471104](http://bugs.debian.org/471104)).
Now, if no timezone is configured anywhere, then such a Debian system (it’s in lenny and sid, not in etch), will use “System/Localtime” as the default timezone, and PHP is patched to resolve meaningful data for this identifier. So `DateTime`, `DateTimeZone` etc work fine, because they all use this change that makes them look at `/etc/localtime`, but… we cannot get the actual timezone name, only the abbreviation, which is useless as it’s not authoritative in many cases (example: actual timezone “Asia/Novosibirsk” returns “System/Localtime”, but “NOVT” as the abbreviation).
`date_default_timezone_get()` returns “System/Localtime”, not the resolved value. Same with `DateTimeZone` or anything in `DateTime`.
Now, of course we could simply determine the offset of the resulting timezone and create an “anonymous” timezone, or the corresponding “GMT+x” one, but that doesn’t give us correct daylight saving time information for the timezone in question, so we cannot do any kind of calculations properly.
So basically, we cannot handle that `System/Localtime` stuff at all, because the stupid patch does it wrong, and because it’s useless, and because once again, some guy from the $random_linux_distribution camp thought he knew better.
I really can’t be bothered to implement yet another workaround. Debian and Ubuntu are causing us nothing but trouble.
Oh, also, Redhat/Fedora might do the same crap (looks like they didn’t include it yet): https://bugzilla.redhat.com/show_bug.cgi?id=469532
God fucking damnit. What kind of a bullcrap idea is this.
Oh and Debian guys keep pointing at PHP in #debian on freenode. Great. They’re also saying that it’s only likely to be fixed if the application(s) affected by it are sufficiently “popular”, whatever that means.
Title changed from “[Expletive] Fucking Debian fucking ruined their fucking PHP package once again, and now we need to waste fucking time to fucking fix it” to “[EXPLETIVE] Fucking Debian fucking ruined their fucking PHP package once again, and now we need to waste fucking time to fucking fix it”
(In 75f4659056f3fccd4f52064c779cc386592411eb) Fixed #1008: [EXPLETIVE] Fucking Debian fucking ruined their fucking PHP package once again, and now we need to waste fucking time to fucking fix it
(In 309e2ba55ac3303361cce1cfed198a6bd7957b4b) ported [3659/branches/0.11], refs #1008
Attachment: Logs of the discussion in #debian on irc.freenode.net today; I removed messages unrelated to the discussion and join/part/quit events
https://github.com/agavi/trac-ticket-attachments/blob/master/1008/debian_chatlog (8.5 kB)
I’m working with the Debian PHP maintenance team to bundle up 5.3. If you want this changed in Debian, file a bug so I have something to point to.