Re: timezones & date() breakage
| From: | Derick Rethans | Date: | Tue, 27 Sep 2005 13:58:27 +0000 |
| Subject: | Re: timezones & date() breakage | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-19202@lists.php.net to get a copy of this message | ||
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
> IA>>This "incantation" is the standard name for your timezone across most
> IA>>systems. Out of curiosity I've just tried "IDT" timezone on 3 machines
> IA>>(Linux, FreeBSD and OpenSolaris) neither of'em supported it. However,
> IA>>they all supported "Israel/Tel Aviv", which is the real name for your
> IA>>timezone.
>
> That is all fine and dandy, but if there's no way to find "real name",
There is but I was not allowed to enable those functions in PHP 5.1. If
you compile with -DEXPERIMENTAL_DATE_SUPPORT, you have a function
timezone_identifiers_list() which returns a list with all the support
settings. The function timezone_abbreviations_list() returns the known
mappings between obsolete, broken, and non-unique timezone abbreviations
and their real Identifier.
> as you call it, to the timezone on the current machine, it basically
> means no user could ever use date() - or application using date() -
> with 5.1 unless he find out it by some external means and definitely
> no automatic install of such application is ever possible. That's the
> problem I want to address.
But it's not an application's problem - it's a server configuration
issue.
> It is especially problematic when we have old working version - so it's
> not that it is impossible to do that. And all applications except PHP deal
> with this problem somehow without external configuration, and can display
> dates without any problem.
"without any problem" - are you kidding me? Have a look at a
presentation I gave about it:
http://derickrethans.nl/files/time-ac2005.pdf
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org