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
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
At 15:33 08/10/2005, Derick Rethans 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
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
- 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
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
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
- 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
At 15:44 08/10/2005, Christian Stocker 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
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
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
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
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
Derick Rethans wrote:
You don't need this, as there is:
http://no.php.net/date_default_timezone_setcool ..
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 wrote:
You don't need this, as there is:
http://no.php.net/date_default_timezone_setcool ..
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
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.
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
How many date formatting functions do we need?
-Andrei
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.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
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
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:
How many date formatting functions do we need?
-Andrei
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.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