Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Timezone stuff - conclusion »

Timezone stuff - conclusion

php.internals

Zeev Suraski

20 years ago
I've been away from email for the last couple of weeks - read through the timezone thread, and didn't really see a conclusion. My suggestion is to restore the old code in its entirely, and introduce the new implementation as new functions with a proper prefix, a-la PHP 2005. I think it's better than an INI entry, and it should be fairly straightforward to implement. I don't think anybody is underestimating Derick's efforts towards building this new date functionality. I certainly don't. I also don't see any reason to break compatibility in something as basic as this, so this should be introduced either as a new (preferably) or optional (less preferably) feature. Zeev

Derick Rethans

20 years ago
On Sat, 8 Oct 2005, Zeev Suraski wrote:
> I've been away from email for the last couple of weeks - read through the > timezone thread, and didn't really see a conclusion. > > My suggestion is to restore the old code in its entirely, and introduce the > new implementation as new functions with a proper prefix, a-la PHP 2005. I > think it's better than an INI entry, and it should be fairly straightforward > to implement.
Nice that you come with this now after I spend a whole bloody week trying to make things as BC as possible, and even on Windows. Derick

Zeev Suraski

20 years ago
At 15:33 08/10/2005, Derick Rethans wrote:
>On Sat, 8 Oct 2005, Zeev Suraski wrote: > > > I've been away from email for the last couple of weeks - read through the > > timezone thread, and didn't really see a conclusion. > > > > My suggestion is to restore the old code in its entirely, and introduce the > > new implementation as new functions with a proper prefix, a-la PHP 2005. I > > think it's better than an INI entry, and it should be fairly > straightforward > > to implement. > >Nice that you come with this now after I spend a whole bloody week >trying to make things as BC as possible, and even on Windows.
Thank you, you're welcome! Zeev

Christian Stocker

20 years ago
On 8.10.2005 15:30 Uhr, Zeev Suraski wrote:
> I've been away from email for the last couple of weeks - read through > the timezone thread, and didn't really see a conclusion.
IIRC the conclusion was, that Derick tries to make the TZ detection better (which was the only BC problem, AFAIK). And according to him, that's now almost solved (except some weird problems on Windows). He even made a pecl package for updating the TZ data easily should that change. If the TZ detection works reliable, I don't see any reason to revert or postpone Dericks work, the timezone handling of his implementation is so much better than the old one, it's really worth the upgrade for everyone having to deal with different timezones. Just my 2 cents. chregu
> > My suggestion is to restore the old code in its entirely, and introduce > the new implementation as new functions with a proper prefix, a-la PHP > 2005. I think it's better than an INI entry, and it should be fairly > straightforward to implement. > > I don't think anybody is underestimating Derick's efforts towards > building this new date functionality. I certainly don't. I also don't > see any reason to break compatibility in something as basic as this, so > this should be introduced either as a new (preferably) or optional (less > preferably) feature. > > Zeev >
-- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | christian.stocker@bitflux.ch | GPG 0x5CE1DECB

Mike Robinson

20 years ago
Christian Stocker wrote:
> IIRC the conclusion was, that Derick tries to make the TZ > detection better (which was the only BC problem, AFAIK). And > according to him, that's now almost solved (except some weird > problems on Windows). > > He even made a pecl package for updating the TZ data easily > should that change. > > If the TZ detection works reliable, I don't see any reason to > revert or postpone Dericks work, the timezone handling of his > implementation is so much better than the old one, it's > really worth the upgrade for everyone having to deal with > different timezones. > > Just my 2 cents.
If I had 2 Phillipino Pesos and they meant anything I'd add them similarly. Mike

Nuno Lopes

20 years ago
> On 8.10.2005 15:30 Uhr, Zeev Suraski wrote: >> I've been away from email for the last couple of weeks - read through >> the timezone thread, and didn't really see a conclusion. > > IIRC the conclusion was, that Derick tries to make the TZ detection > better (which was the only BC problem, AFAIK). And according to him, > that's now almost solved (except some weird problems on Windows).
Yep, even on windows is it almost working at 100% :) And I'm having much more success with the new code, specially on Windows and Solaris.
> He even made a pecl package for updating the TZ data easily should that > change.
Upgrading the TZ data should be as easy as upgrading a PECL package.
> If the TZ detection works reliable, I don't see any reason to revert or > postpone Dericks work, the timezone handling of his implementation is so > much better than the old one, it's really worth the upgrade for everyone > having to deal with different timezones.
Yes it shouldn't be reverted. I think it is working well, and it is already covered by a large amount of test cases, so the BC breaking chances are minimal. Nuno

Zeev Suraski

20 years ago
At 15:44 08/10/2005, Christian Stocker wrote:
>On 8.10.2005 15:30 Uhr, Zeev Suraski wrote: > > I've been away from email for the last couple of weeks - read through > > the timezone thread, and didn't really see a conclusion. > >IIRC the conclusion was, that Derick tries to make the TZ detection >better (which was the only BC problem, AFAIK). And according to him, >that's now almost solved (except some weird problems on Windows). > >He even made a pecl package for updating the TZ data easily should that >change. > >If the TZ detection works reliable, I don't see any reason to revert or >postpone Dericks work, the timezone handling of his implementation is so >much better than the old one, it's really worth the upgrade for everyone >having to deal with different timezones.
Ok, maybe I missed it in the lengthy thread. Contrary to what Derick may have thought from my response, I wasn't trying to reopen the discussion, just to make sure it doesn't linger to death. Zeev

Ilia A.

20 years ago
Zeev Suraski wrote:
> Ok, maybe I missed it in the lengthy thread.
I suspect that is very much the case. Derick has been working quite diligently over the last little while at getting the BC problems solved and as far as I know all but a few Win32 issues have been resolved to everyones satisfaction. Ilia

Lukas Smith

20 years ago
Ilia Alshanetsky wrote:
> Zeev Suraski wrote: > >>Ok, maybe I missed it in the lengthy thread. > > > > I suspect that is very much the case. Derick has been working quite > diligently over the last little while at getting the BC problems solved > and as far as I know all but a few Win32 issues have been resolved to > everyones satisfaction.
And for this situation there is the ini flag as a fallback .. BTW: while ini_set() has a tendency to be disabled I remember Stig added set_include_path() so that users might have a change of still fixing their include path to handle their PEAR paths .. maybe we need something like this as well for this timezone setting .. or maybe we need a new ini_set method for things deemed not security relevant that shared hosters may leave alone ..? regards, Lukas

Derick Rethans

20 years ago
On Sat, 8 Oct 2005, Lukas Smith wrote:
> Ilia Alshanetsky wrote: > > Zeev Suraski wrote: > > > > >Ok, maybe I missed it in the lengthy thread. > > > > > > > > I suspect that is very much the case. Derick has been working quite > > diligently over the last little while at getting the BC problems solved > > and as far as I know all but a few Win32 issues have been resolved to > > everyones satisfaction. > > And for this situation there is the ini flag as a fallback .. > > BTW: while ini_set() has a tendency to be disabled I remember Stig added > set_include_path() so that users might have a change of still fixing their > include path to handle their PEAR paths .. maybe we need something like this > as well for this timezone setting .. or maybe we need a new ini_set method for > things deemed not security relevant that shared hosters may leave alone ..?
You don't need this, as there is: http://no.php.net/date_default_timezone_set regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Lukas Smith

20 years ago
Derick Rethans wrote:
> You don't need this, as there is: > http://no.php.net/date_default_timezone_set
cool .. now we only need to get the list of possible legal TZ's documented (or linked from the docs) .. atleast I do not see it yet (but it might be just me not seeing it at 5 am after coming home from a party .. just had too much time thinking on the bike ride home). regards, Lukas

Nuno Lopes

20 years ago
> Derick Rethans wrote: > >> You don't need this, as there is: >> http://no.php.net/date_default_timezone_set > > cool .. > > now we only need to get the list of possible legal TZ's documented (or > linked from the docs) .. atleast I do not see it yet (but it might be just > me not seeing it at 5 am after coming home from a party .. just had too > much time thinking on the bike ride home).
Derick added that yesterday. While the manual isn't rebuilt, take a look at http://livedocs.phpdoc.info/index.php?l=en&q=timezones This page is linked from the date_default_timezone_set() page. Nuno

Derick Rethans

20 years ago
On Sun, 9 Oct 2005, Lukas Smith wrote:
> Derick Rethans wrote: > > > You don't need this, as there is: > > http://no.php.net/date_default_timezone_set > > cool .. > > now we only need to get the list of possible legal TZ's documented (or linked > from the docs) .. atleast I do not see it yet (but it might be just me not > seeing it at 5 am after coming home from a party .. just had too much time > thinking on the bike ride home).
I started the build when I got home at 3am ;-) It's now online: http://www.php.net/manual/en/timezones.php, I'll check later today where I want to link this in exactly. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Mike Robinson

20 years ago
> I started the build when I got home at 3am ;-) It's now online: > http://www.php.net/manual/en/timezones.php, I'll check later > today where I want to link this in exactly.
Nice work on this TZ stuff Derick. My thanks. Best, Mike Robinson

Lester Caine

20 years ago
Zeev Suraski wrote:
>> If the TZ detection works reliable, I don't see any reason to revert or >> postpone Dericks work, the timezone handling of his implementation is so >> much better than the old one, it's really worth the upgrade for everyone >> having to deal with different timezones. > > Ok, maybe I missed it in the lengthy thread. > > Contrary to what Derick may have thought from my response, I wasn't > trying to reopen the discussion, just to make sure it doesn't linger to > death.
I think that the only thing that is missing is that there is no way of identifying the CLIENT time/daylight zone so we have to get users to register their current location in order to use it on anything other than a local server :( Of cause the main problem is that if we use it then applications will be totally tied to a version of PHP which has yet to actually be accepted by ISP! I think THAT was the main reason for wanting a plug in module that could be back ported?
-- Lester Caine ----------------------------- L.S.Caine Electronic Services Treasurer - Firebird Foundation Inc.

Derick Rethans

20 years ago
On Sat, 8 Oct 2005, Lester Caine wrote:
> Zeev Suraski wrote: > > > > If the TZ detection works reliable, I don't see any reason to revert or > > > postpone Dericks work, the timezone handling of his implementation is so > > > much better than the old one, it's really worth the upgrade for everyone > > > having to deal with different timezones. > > > > Ok, maybe I missed it in the lengthy thread. > > > > Contrary to what Derick may have thought from my response, I wasn't trying > > to reopen the discussion, just to make sure it doesn't linger to death. > > I think that the only thing that is missing is that there is no way of > identifying the CLIENT time/daylight zone so we have to get users to register > their current location in order to use it on anything other than a local > server :(
Well yeah, but that's just simply impossible (and has nothing to do with the new code anyway). regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Andrei Zmievski

20 years ago
How many date formatting functions do we need? -Andrei Zeev Suraski wrote:

Derick Rethans

20 years ago
On Mon, 10 Oct 2005, Andrei Zmievski wrote:
> How many date formatting functions do we need?
Two, one for non-locale based formatting, and one for locale based formatting. Unfortunately as we only have a 32 bit integer we also need some outside of the current date() one, so that makes 4 (if we count strftime(), which relies on system locales YUCK!, too). Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Zeev Suraski

20 years ago
As many as make sense. But this thread is dead, if all goes well and the work Derick has done sorts things out. Zeev At 01:18 11/10/2005, Andrei Zmievski wrote: