Re: timezones & date() breakage
| From: | Stanislav Malyshev | Date: | Tue, 27 Sep 2005 14:13:37 +0000 |
| Subject: | Re: timezones & date() breakage | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-19204@lists.php.net to get a copy of this message | ||
DR>>There is but I was not allowed to enable those functions in PHP 5.1. If
DR>>you compile with -DEXPERIMENTAL_DATE_SUPPORT, you have a function
DR>>timezone_identifiers_list() which returns a list with all the support
DR>>settings. The function timezone_abbreviations_list() returns the known
DR>>mappings between obsolete, broken, and non-unique timezone abbreviations
DR>>and their real Identifier.
This still won't help me, for example, if current TZ rules change and PHP
is not updated. For some countries, it does change. And it still means the
app won't work with 5.1 release. And I stil don't see why one of the TZ
settings couldn't be just "use my system settings"? OK, I will lose all
advanced stuff - in this particular case I am ready for that. Why not
allow this option?
DR>>But it's not an application's problem - it's a server configuration
DR>>issue.
You can't tell "Not My Problem" to the user - he couldn't care less if he
sees wrong dates because php.ini is wrong or datetime.c is wrong or
getmydate.php is wrong - for him the whole system is broken. And the
bigger problem is that you don't give the PHP app author means to fix it
- not at least in PHP 5.1. That's not just server configuration issue -
that's server configuration issue that application author couldn't ever
fix or route around. And which we could easily fix if we allowed to use
system settings. Without that, the only advice app author could give the
user as for now is Jani's "don't upgrade". Then the question is - why to
write the code that you suggest not to upgrade to?
DR>>"without any problem" - are you kidding me? Have a look at a
DR>>presentation I gave about it:
DR>>http://derickrethans.nl/files/time-ac2005.pdf
I didn't mean "there were no problems in data functions at all in older
PHP" - I'm sure there was if it required rewrite. I did mean "default
configuration gave expected results without any additional hoops to jump
through". Meaning, I could just take any PHP and run date() and get my
systems date - now I can't. I'm sure there were a lot of things I couldn't
do before and now I can - but that doesn't help me with the problem. I
can't say to the user "you don't see correct time in the app, but that's
because if you ever needed to know what time is it now on Madagaskar I
could tell you".
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115