I see that in PHP5.1 the handling of date() was changed, and now I see
that at least on my machine (and all machines we have, actually) all
date() functions suddently started to return dates in UTC and spit out
warnings.
I understand that it was due to some improvement of timezone
handling, but seems that this improvement didn't actually improve things,
at least not for us.
While everything worked just fine before, I can not use date() function
anymore. I guess this is because the built-in library that is now in
charge for timezones does not recognize my timezone. I think using library
that has internal fixed timezone list which is not the same as OSs
tiemzone list is extermely unfortunate choice. While setting up timezone
on user's OS is pretty much standard procedure (at least, any qualified
sysadmin knows to do this and one can rely on it being done before PHP is
run), I have no idea how can I make PHP to recognize my timezone now and
thus besically what I have is that all date() functions are broken for me.
Is there any easy way to fix it? If so, it should be explicitly stated in
date()'s manual, if not, I think it should be fixed ASAP.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
While everything worked just fine before, I can not use
date()function
anymore.
Sure you can, you just set the timezone yourself with the date.timezone
setting. If you had e_strict errors turned on, you would have seen a
warning about this.
I guess this is because the built-in library that is now in charge
for timezones does not recognize my timezone.
What is the timezone abbreviation (you can not call it a "timezone" as
an abbreviation is not unique per sé)? If you tell us what name is not
recognised, we can add it.
I think using library that has
internal fixed timezone list which is not the same as OSs tiemzone list is
extermely unfortunate choice.
I totally disagree. It's extremely annoying if an application that uses
timezones can not use it on another platform because the data for it is
not there, or there is another abbreviation/name associated with it.
While setting up timezone on user's OS is pretty
much standard procedure (at least, any qualified sysadmin knows to do this and
one can rely on it being done before PHP is run), I have no idea how can I
make PHP to recognize my timezone now and thus besically what I have is that
alldate()functions are broken for me.
Turn on E_STRICT error reporting... and see the documentation:
http://php.net/manual/en/ref.datetime.php
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
DR>>Sure you can, you just set the timezone yourself with the
DR>>date.timezone setting. If you had e_strict errors turned on, you would
DR>>have seen a warning about this.
Not so easy. Tried that - it complains it doesn't know my timezone.
DR>>What is the timezone abbreviation (you can not call it a "timezone" as
DR>>an abbreviation is not unique per s?)? If you tell us what name is not
DR>>recognised, we can add it.
The timezone is named IDT currently, but the problem is not in this - the
problem is in "we can add it". OK, we add this one - how many ones out
there we didn't add yet? So we will be fixing it for years and still get
it not work in some places - while before the "improvement" it worked!
Most probably you will naver have the full list - since both Unix and
Windows allows to extend their timezone databases, and even more funny
thing - they allow changing rules for timezones. Does this library use OS
timezone database? I guess not, otherwise it would know my TZ by name.
Then even if you would add the name there, who would guarantee you that
the rules your library is using is the same rules the rest of OS is using?
That your app won't jump from DST to standard a week too early?
DR>>I totally disagree. It's extremely annoying if an application that
DR>>uses timezones can not use it on another platform because the data for
DR>>it is not there, or there is another abbreviation/name associated with
DR>>it.
It is much more annoying if application running on my own platform stops
working even without moving it anywhere and to fix it one needs actually
patch C code and even then he can't be sure it would work.
And I don't see why you one can't use OS services to check timezones -
AFAIK most OSes provide these.
DR>>Turn on E_STRICT error reporting... and see the documentation:
DR>>http://php.net/manual/en/ref.datetime.php
Can you quote where it says how can I fix it? And more importantly - how
someone as a PHP programmer and not C programmer can fix it if your
library doesn't know his timezone?
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
The timezone is named IDT currently, but the problem is not in this - the
problem is in "we can add it". OK, we add this one - how many ones out
there we didn't add yet? So we will be fixing it for years and still get
it not work in some places - while before the "improvement" it worked!
Using a timezone abbreviation is a bad thing anyway. Your timezone is
"Isreal/Tel Aviv" and currently your abbreviation is IDT. IDT is not a
timezone, it is the description of the period in which you use DST in
combination with Israel time.
Most probably you will naver have the full list - since both Unix and
Windows allows to extend their timezone databases, and even more funny
thing - they allow changing rules for timezones. Does this library use OS
timezone database?
As I already said, no, it does not use the OS's timezone database for
the obvious reasons mentioned.
Then even if you would add the name there, who would guarantee you that
the rules your library is using is the same rules the rest of OS is using?
That your app won't jump from DST to standard a week too early?
The timezone database that I use is updated from the respected Olson
database. All distributions use this (and I hope also Windows). If the
distributions don't, then their information is incorrect and not
PHP's. This is one of the reasons why we have our own database.
And I don't see why you one can't use OS services to check timezones -
AFAIK most OSes provide these.
But they are totally crippled. Timezone abbreviations are not unique
(EST is both Eastern US, and Eastern Australia for example) and do NOT
provide you with a solid way of handling all the complicate matters -
believe me, i've been there. There is no other sensible way then doing
this ourselves - the only thing is that you actually have to specify
your timezone in your php.ini file now.
DR>>Turn on
E_STRICTerror reporting... and see the documentation:
DR>>http://php.net/manual/en/ref.datetime.phpCan you quote where it says how can I fix it? And more importantly - how
someone as a PHP programmer and not C programmer can fix it if your
library doesn't know his timezone?
date.timezone string
The default timezone used by all date/time functions if the TZ
environment variable isn't set. The precedence order is described in the
date_default_timezone_get() page.
http://no2.php.net/manual/en/function.date-default-timezone-get.php
says:
This functions returns the default timezone, using the
following "guess" order:
* The timezone set using the `date_default_timezone_set()` function (if any)
* The TZ environment variable (if non empty)
* The date.timezone ini option (if set)
* "magical" guess (if the operating system supports it)
* If none of the above options succeeds, return UTC
The one that the C code recognizes is already a fallback in case you
don't set this setting. You don't need to change any C code in order to
pick the correct timezone. (And for you you should use "Asia/Tel_Aviv"
as setting).
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Derick Rethans wrote:
http://no2.php.net/manual/en/function.date-default-timezone-get.php
says:This functions returns the default timezone, using the
following "guess" order:* The timezone set using the `date_default_timezone_set()` function (if any) * The TZ environment variable (if non empty) * The date.timezone ini option (if set) * "magical" guess (if the operating system supports it) * If none of the above options succeeds, return UTC
I'm coming in late here - but being in the middle of trying to configure
a system to provide calendars across time and daylight saving zones,
I've been deep in this!
I have no problem with the time AT THE SERVER! What I need to know is
what daylight saving zone the client is in so I can build the correct
calendar for March/April or October/November.
ALL the data on the server is stored UTC so I could not care less
which zone it is in :)
The ONLY solution I currently have is to get the client to set their
time/daylight zone in their profile on the server ?
--
Lester Caine
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
I'm coming in late here - but being in the middle of trying to
configure a system to provide calendars across time and daylight
saving zones, I've been deep in this! I have no problem with the time
AT THE SERVER! What I need to know is what daylight saving zone the
client is in so I can build the correct calendar for March/April or
October/November. ALL the data on the server is stored UTC so I
could not care less which zone it is in :) The ONLY solution I
currently have is to get the client to set their time/daylight zone in
their profile on the server ?
I've no clue what you mean here... sorry. Try to explain a bit better
what you want to do. Do you want to render events' dates with the
correct timezone while your data is in UTC (as Unix timestamp?)?
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Derick Rethans wrote:
I'm coming in late here - but being in the middle of trying to
configure a system to provide calendars across time and daylight
saving zones, I've been deep in this! I have no problem with the time
AT THE SERVER! What I need to know is what daylight saving zone the
client is in so I can build the correct calendar for March/April or
October/November. ALL the data on the server is stored UTC so I
could not care less which zone it is in :) The ONLY solution I
currently have is to get the client to set their time/daylight zone in
their profile on the server ?I've no clue what you mean here... sorry. Try to explain a bit better
what you want to do. Do you want to render events' dates with the
correct timezone while your data is in UTC (as Unix timestamp?)?
Yes
Client currently supplies tz_offset, but that does not identify the
daylight saving offset so you can not show the correct shifts of
calendar times for the 'other' daylight offset :(
The FIRST problem I had was STOPPING the display from being offset by
the SERVER daylight saving setting!
There is absolutely no reason that date() should supply anything other
than the current UTC time. It is the only thing that is actually RIGHT!
--
Lester Caine
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
LC>>There is absolutely no reason that date() should supply anything other
LC>>than the current UTC time. It is the only thing that is actually
LC>>RIGHT!
Sure there is. If you want to display what time is it now, you don't need
UTC. Do you have your watch in UTC and your wall clock in your home in
UTC?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
Stanislav Malyshev wrote:
LC>>There is absolutely no reason that
date()should supply anything other
LC>>than the current UTC time. It is the only thing that is actually
LC>>RIGHT!Sure there is. If you want to display what time is it now, you don't need
UTC. Do you have your watch in UTC and your wall clock in your home in
UTC?
ACTUALLY - all the server clocks are set to GMT - that way I know who
ever enters data, the timestamp is always correct, what ever their local
time ;)
--
Lester Caine
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
LC>>> UTC. Do you have your watch in UTC and your wall clock in your home in
LC>>> UTC?
LC>>
LC>>ACTUALLY - all the server clocks are set to GMT - that way I know who ever
LC>>enters data, the timestamp is always correct, what ever their local time ;)
I am starting to get an impression that you reply to me without reading
what I wrote. Once more: when I need to display current time for this
machine, I don't need UTC. Not everybody runs your particular
application, other people have other needs.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
LC>>> UTC. Do you have your watch in UTC and your wall clock in your home in
LC>>> UTC?
LC>>
LC>>ACTUALLY - all the server clocks are set to GMT - that way I know who ever
LC>>enters data, the timestamp is always correct, what ever their local time ;)I am starting to get an impression that you reply to me without reading
what I wrote. Once more: when I need to display current time for this
machine, I don't need UTC.
But you do need UTC somewhere, as all date code (OS, applications)
use UTC timestamps to calculate the current time.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
DR>>But you do need UTC somewhere, as all date code (OS, applications)
DR>>use UTC timestamps to calculate the current time.
So? They are able to use it transparently without requiring me to do any
special configuration for each application - they just go out and display
the right date. Only PHP 5.1 needs separate configuration for that. This
is broken.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
DR>>But you do need UTC somewhere, as all date code (OS, applications)
DR>>use UTC timestamps to calculate the current time.So? They are able to use it transparently without requiring me to do any
special configuration for each application - they just go out and display
the right date. Only PHP 5.1 needs separate configuration for that. This
is broken.
I wouldn't call it broken, just less inituitive. But besides that point,
I looked at some data and have a patch that allows the timezone guessing
code to also check against the GMT offset, and not only the
abbreviation. This means that with these DB entries:
{ "idt", 1, -HOUR ( 3), "Asia/Tel_Aviv" },
{ "idt", 1, -HOUR (4.5), "Iran/Teheran" },
{ "idt", 1, -HOUR (6.5), "Asia/Calcutta" },
IDT will be recognised correctly for all three variations. There are two
ways of creating the database for this:
- by iterating over the timezone database and collecting all the
possible combinations - by copying the data from http://www.worldtimezone.com/wtz-names/timezonenames.html
I think option 1 is the better here, and I'll play with a script to
generated that data tonight. After that I'll commit the patch too.
I think this shoul adequately solve the problems that you encountered.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
DR>>I think this shoul adequately solve the problems that you encountered.
Thanks for finding a way to solve it at least for this example. But I am
still concerned that it would solve the problem for me, but what if I
install it somewhere in Finland or Australia and their TZ is not working
too because it concides with Fiji and Austria and your Db doesn't support
it? Though if the algorithm takes also GMT offset into account it may work
(unless we have two TZs with same abbreviation, same current settings but
different rules - I don't know if such beasts exist).
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
DR>>I think this shoul adequately solve the problems that you encountered.
Thanks for finding a way to solve it at least for this example. But I am
still concerned that it would solve the problem for me, but what if I
install it somewhere in Finland or Australia and their TZ is not working
too because it concides with Fiji and Austria and your Db doesn't support
it?
I don't see your point here, can you clarify this with a little example
perhaps?
Though if the algorithm takes also GMT offset into account it may work
(unless we have two TZs with same abbreviation, same current settings but
different rules - I don't know if such beasts exist).
I think that's a very marginal problem, perhaps a problem for 0.1% of
the world population. I think we can live with that.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
On Wed, 28 Sep 2005 15:02:38 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:
I think that's a very marginal problem, perhaps a problem for 0.1% of
the world population. I think we can live with that.
Is it the same 0.1% as in 5.0.5?
DR>>> too because it concides with Fiji and Austria and your Db doesn't support
DR>>> it?
DR>>
DR>>I don't see your point here, can you clarify this with a little example
DR>>perhaps?
Well, that's the same problem I had but it would be not IDT, but, say,
some FDT which has multiple timezones too. Now if you say it would be
generated from some big TZ database and not just fixed for particular
case then I guess it would not be a concern.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
DR>>> too because it concides with Fiji and Austria and your Db doesn't support
DR>>> it?
DR>>
DR>>I don't see your point here, can you clarify this with a little example
DR>>perhaps?Well, that's the same problem I had but it would be not IDT, but, say,
some FDT which has multiple timezones too. Now if you say it would be
generated from some big TZ database and not just fixed for particular
case then I guess it would not be a concern.
Right, of course fixing it for IDT only would be silly :)
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
This discussion has been interesting. ;)
These sorts of problems have come up many times during the course of PHP
development. Things that were implemented to solve a very specific
local problem ended up causing grief when the scope of PHP grew. Think
of things like magic_quotes_gpc and case-insensitive function names.
Both of these actually made perfect sense when they were implemented but
as things got bigger they started to get in the way and today most
people wish we had broken backwards compatibility a long time ago and
gotten rid of those early on.
We have tended towards not breaking BC over the years leaving quite a
bit of cruft around for people to deal with. Watching Derick try to
buck that trend has been fun and I think he deserves a bit less vitriol
for his efforts.
His new date() code is obviously better and more portable than what we
had. So it comes down to a pretty simple decision that doesn't need all
that much emotion poured into it:
Do we take the BC hit now to get clean and consistent date/time
handling or do we stay with the BC over all else path we usually
take? Either way we have pain. If we break BC there will be plenty
of pain from very vocal users who feel personally wronged that we broke
their code, and if we don't break BC and go with two different
date/time systems we have to live with these two systems forever and
it we will need to hold up the 5.1 release for a couple of weeks.
I actually lean more towards the keeping BC side here but was hoping the
new date implementation could get to the point of minimal BC breakage or
perhaps even none with some sort of compatibility mode. I think there
is a lot to be said for not having two different implementations so for
the folks who feel so strongly about this, pitch in with some testing
and help make this new implementation backward compatible. It should be
possible to get this timezone mapping to the point where it addresses
the majority of timezone name overlaps in the world.
-Rasmus
When I agreed to commit this for PHP 5.1, Derick promised that this
was going to completely keep BC. That is obviously not happening.
While I appreciate his efforts, I think as with the reference change,
this will cause much more widespread pain than we can even imagine.
Without being an expert on this timezone stuff, I suggest to have the
ability to get the old behavior, wether it's reverting to the system
date, either if we can't find the timezone entry, or if that is a
problem due to overlaps, then have a setting which allows to get the
old behavior. I don't even mind if it's called
date.old_broken_timezone_behavior. We did something similar in oci8
in order not to break apps.
Andi
At 09:01 AM 9/28/2005, Rasmus Lerdorf wrote:
This discussion has been interesting. ;)
These sorts of problems have come up many times during the course of PHP
development. Things that were implemented to solve a very specific
local problem ended up causing grief when the scope of PHP grew. Think
of things like magic_quotes_gpc and case-insensitive function names.
Both of these actually made perfect sense when they were implemented but
as things got bigger they started to get in the way and today most
people wish we had broken backwards compatibility a long time ago and
gotten rid of those early on.We have tended towards not breaking BC over the years leaving quite a
bit of cruft around for people to deal with. Watching Derick try to
buck that trend has been fun and I think he deserves a bit less vitriol
for his efforts.His new
date()code is obviously better and more portable than what we
had. So it comes down to a pretty simple decision that doesn't need all
that much emotion poured into it:Do we take the BC hit now to get clean and consistent date/time
handling or do we stay with the BC over all else path we usually
take? Either way we have pain. If we break BC there will be plenty
of pain from very vocal users who feel personally wronged that we broke
their code, and if we don't break BC and go with two different
date/time systems we have to live with these two systems forever and
it we will need to hold up the 5.1 release for a couple of weeks.I actually lean more towards the keeping BC side here but was hoping the
new date implementation could get to the point of minimal BC breakage or
perhaps even none with some sort of compatibility mode. I think there
is a lot to be said for not having two different implementations so for
the folks who feel so strongly about this, pitch in with some testing
and help make this new implementation backward compatible. It should be
possible to get this timezone mapping to the point where it addresses
the majority of timezone name overlaps in the world.-Rasmus
--
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/
I agree; date() in 5.1 should default to the older "broken" code for
BC and have a toggle for the new stuff. We could also issue a
deprecation notice to warn people about a future move to the new code
in PHP 6.
This way we get the "best" of both worlds; BC is preserved for the
masses of existing code and we get more QA on the new implementation
ready for going production with the new code in PHP 6.
--Wez.
When I agreed to commit this for PHP 5.1, Derick promised that this
was going to completely keep BC. That is obviously not happening.
While I appreciate his efforts, I think as with the reference change,
this will cause much more widespread pain than we can even imagine.
Without being an expert on this timezone stuff, I suggest to have the
ability to get the old behavior, wether it's reverting to the system
date, either if we can't find the timezone entry, or if that is a
problem due to overlaps, then have a setting which allows to get the
old behavior. I don't even mind if it's called
date.old_broken_timezone_behavior. We did something similar in oci8
in order not to break apps.Andi
At 09:01 AM 9/28/2005, Rasmus Lerdorf wrote:
This discussion has been interesting. ;)
These sorts of problems have come up many times during the course of PHP
development. Things that were implemented to solve a very specific
local problem ended up causing grief when the scope of PHP grew. Think
of things like magic_quotes_gpc and case-insensitive function names.
Both of these actually made perfect sense when they were implemented but
as things got bigger they started to get in the way and today most
people wish we had broken backwards compatibility a long time ago and
gotten rid of those early on.We have tended towards not breaking BC over the years leaving quite a
bit of cruft around for people to deal with. Watching Derick try to
buck that trend has been fun and I think he deserves a bit less vitriol
for his efforts.His new
date()code is obviously better and more portable than what we
had. So it comes down to a pretty simple decision that doesn't need all
that much emotion poured into it:Do we take the BC hit now to get clean and consistent date/time
handling or do we stay with the BC over all else path we usually
take? Either way we have pain. If we break BC there will be plenty
of pain from very vocal users who feel personally wronged that we broke
their code, and if we don't break BC and go with two different
date/time systems we have to live with these two systems forever and
it we will need to hold up the 5.1 release for a couple of weeks.I actually lean more towards the keeping BC side here but was hoping the
new date implementation could get to the point of minimal BC breakage or
perhaps even none with some sort of compatibility mode. I think there
is a lot to be said for not having two different implementations so for
the folks who feel so strongly about this, pitch in with some testing
and help make this new implementation backward compatible. It should be
possible to get this timezone mapping to the point where it addresses
the majority of timezone name overlaps in the world.-Rasmus
--
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/
Bah, hit send too soon...
This way we get the "best" of both worlds; BC is preserved for the
masses of existing code and we get more QA on the new implementation
from early adopters
ready for going production with the new code in PHP 6.
--Wez.
I agree, and we should currently have both so that we can migrate
users to Derick's new code. Derick, I think you need to return the
support for the old functionality (it can probably be done quite
easily by taking the old code as-is). We should then have an INI
option which selects between the two (I hate INIs but I don't see
much of a way around it).
To be realistic, considering the possible breakage in apps, I don't
believe 5.1 can be released in the current state.
Thanks,
Andi
At 04:58 PM 9/28/2005, Wez Furlong wrote:
I agree;
date()in 5.1 should default to the older "broken" code for
BC and have a toggle for the new stuff. We could also issue a
deprecation notice to warn people about a future move to the new code
in PHP 6.This way we get the "best" of both worlds; BC is preserved for the
masses of existing code and we get more QA on the new implementation
ready for going production with the new code in PHP 6.--Wez.
When I agreed to commit this for PHP 5.1, Derick promised that this
was going to completely keep BC. That is obviously not happening.
While I appreciate his efforts, I think as with the reference change,
this will cause much more widespread pain than we can even imagine.
Without being an expert on this timezone stuff, I suggest to have the
ability to get the old behavior, wether it's reverting to the system
date, either if we can't find the timezone entry, or if that is a
problem due to overlaps, then have a setting which allows to get the
old behavior. I don't even mind if it's called
date.old_broken_timezone_behavior. We did something similar in oci8
in order not to break apps.Andi
At 09:01 AM 9/28/2005, Rasmus Lerdorf wrote:
This discussion has been interesting. ;)
These sorts of problems have come up many times during the course of PHP
development. Things that were implemented to solve a very specific
local problem ended up causing grief when the scope of PHP grew. Think
of things like magic_quotes_gpc and case-insensitive function names.
Both of these actually made perfect sense when they were implemented but
as things got bigger they started to get in the way and today most
people wish we had broken backwards compatibility a long time ago and
gotten rid of those early on.We have tended towards not breaking BC over the years leaving quite a
bit of cruft around for people to deal with. Watching Derick try to
buck that trend has been fun and I think he deserves a bit less vitriol
for his efforts.His new
date()code is obviously better and more portable than what we
had. So it comes down to a pretty simple decision that doesn't need all
that much emotion poured into it:Do we take the BC hit now to get clean and consistent date/time
handling or do we stay with the BC over all else path we usually
take? Either way we have pain. If we break BC there will be plenty
of pain from very vocal users who feel personally wronged that we broke
their code, and if we don't break BC and go with two different
date/time systems we have to live with these two systems forever and
it we will need to hold up the 5.1 release for a couple of weeks.I actually lean more towards the keeping BC side here but was hoping the
new date implementation could get to the point of minimal BC breakage or
perhaps even none with some sort of compatibility mode. I think there
is a lot to be said for not having two different implementations so for
the folks who feel so strongly about this, pitch in with some testing
and help make this new implementation backward compatible. It should be
possible to get this timezone mapping to the point where it addresses
the majority of timezone name overlaps in the world.-Rasmus
--
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/--
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/
Andi Gutmans wrote:
I agree, and we should currently have both so that we can migrate users
to Derick's new code. Derick, I think you need to return the support for
the old functionality (it can probably be done quite easily by taking
the old code as-is). We should then have an INI option which selects
between the two (I hate INIs but I don't see much of a way around it).
To be realistic, considering the possible breakage in apps, I don't
believe 5.1 can be released in the current state.
We should be able to run 5.1 on a 5.0 system and at worst get warnings -
hidden potential differences are something to be avoided ;)
Would it be possible to have dev snapshots of PHP6 on windows where
THIS sort of thing can be played with in earnest and the migration
notes worked out. ( Probably need those from both PHP4 and PHP5 :( )
I started playing with PHP5 well before it was finally released so never
bothered with PHP4 in production. Having to try and maintain BC with
PHP4 in OS projects is becoming a pain, and all these 'subtle changes'
being applied to PHP5 and back ported to PHP4 are just adding
unnecessary work. PLEASE can we have a PROPER freeze on some back
porting and set a rule that once PHP6 is more accessible ( I NEED
UNICODE ;) ) then nothing will be applied to PHP4 that requires any code
changes and ideally PHP5 as well ?
Hopefully the tidy UNICODE implementation in PHP6 will provide enough
incentive for 4 and 5 to be sidelined? But we are probably going to need
a 'code tidier' that identifies areas that need work in legacy code?
--
Lester Caine
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
The "masses" don't have to update. The old broken `date()` is still
in PHP 4.4.0 and PHP 5.0.x.
Please stop the BC fud, this is not about a bugfix release but
something a bit bigger thing.
One other solution: we can always change PHP_5_1 to PHP_6
and do all other nice "BC" breaks too while we're at it..
And start calling HEAD PHP 7.0 =)
--Jani
I agree;
date()in 5.1 should default to the older "broken" code for
BC and have a toggle for the new stuff. We could also issue a
deprecation notice to warn people about a future move to the new code
in PHP 6.This way we get the "best" of both worlds; BC is preserved for the
masses of existing code and we get more QA on the new implementation
ready for going production with the new code in PHP 6.--Wez.
When I agreed to commit this for PHP 5.1, Derick promised that this
was going to completely keep BC. That is obviously not happening.
While I appreciate his efforts, I think as with the reference change,
this will cause much more widespread pain than we can even imagine.
Without being an expert on this timezone stuff, I suggest to have the
ability to get the old behavior, wether it's reverting to the system
date, either if we can't find the timezone entry, or if that is a
problem due to overlaps, then have a setting which allows to get the
old behavior. I don't even mind if it's called
date.old_broken_timezone_behavior. We did something similar in oci8
in order not to break apps.Andi
At 09:01 AM 9/28/2005, Rasmus Lerdorf wrote:
This discussion has been interesting. ;)
These sorts of problems have come up many times during the course of PHP
development. Things that were implemented to solve a very specific
local problem ended up causing grief when the scope of PHP grew. Think
of things like magic_quotes_gpc and case-insensitive function names.
Both of these actually made perfect sense when they were implemented but
as things got bigger they started to get in the way and today most
people wish we had broken backwards compatibility a long time ago and
gotten rid of those early on.We have tended towards not breaking BC over the years leaving quite a
bit of cruft around for people to deal with. Watching Derick try to
buck that trend has been fun and I think he deserves a bit less vitriol
for his efforts.His new
date()code is obviously better and more portable than what we
had. So it comes down to a pretty simple decision that doesn't need all
that much emotion poured into it:Do we take the BC hit now to get clean and consistent date/time
handling or do we stay with the BC over all else path we usually
take? Either way we have pain. If we break BC there will be plenty
of pain from very vocal users who feel personally wronged that we broke
their code, and if we don't break BC and go with two different
date/time systems we have to live with these two systems forever and
it we will need to hold up the 5.1 release for a couple of weeks.I actually lean more towards the keeping BC side here but was hoping the
new date implementation could get to the point of minimal BC breakage or
perhaps even none with some sort of compatibility mode. I think there
is a lot to be said for not having two different implementations so for
the folks who feel so strongly about this, pitch in with some testing
and help make this new implementation backward compatible. It should be
possible to get this timezone mapping to the point where it addresses
the majority of timezone name overlaps in the world.-Rasmus
--
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/--
--
Donate @ http://pecl.php.net/wishlist.php/sniper
Disclaimer: Donating money may make me happier and friendlier for a limited period!
Call it FUD if you like; I call it "sleeping easier at night". Like
it or not, PHP is big enough now that these things have become
critical points for larger businesses. To completely replace the
default implementation of a core function with something new is quite
a risk when it's not had enough QA. Take a look at Streams for
example; things are still settling down there from their
(embarrasingly buggy) 4.3 debut.
You could argue that date/time support in PHP is more critical than
streams, and so changing that worries me more.
Whether we intend PHP 5.1 to be a bugfix release or not isn't really
relevant; people will assume that PHP 5.1 is "PHP 5 with some things
fixed and some new things added"... and isn't that really what our
versioning scheme says it will be too?
We're a big enough project to have a responsibility
(http://netevil.org/node.php?nid=427) to our users. Progress isn't
about breaking BC at every turn; take a look at the Solaris approach:
innovate by creating new APIs and ensure stability by preserving
existing APIs. This is a solid, reliable approach to software
development, and improves the quality of sleep for us, people
developing applications with PHP, people paying for PHP applications
and for people using those "critical" applications (banking, travel,
auctions).
--Wez.
The "masses" don't have to update. The old broken `date()` is still in PHP 4.4.0 and PHP 5.0.x. Please stop the BC fud, this is not about a bugfix release but something a bit bigger thing. One other solution: we can always change PHP_5_1 to PHP_6 and do all other nice "BC" breaks too while we're at it.. And start calling HEAD PHP 7.0 =) --JaniI agree;
date()in 5.1 should default to the older "broken" code for
BC and have a toggle for the new stuff. We could also issue a
deprecation notice to warn people about a future move to the new code
in PHP 6.This way we get the "best" of both worlds; BC is preserved for the
masses of existing code and we get more QA on the new implementation
ready for going production with the new code in PHP 6.--Wez.
When I agreed to commit this for PHP 5.1, Derick promised that this
was going to completely keep BC. That is obviously not happening.
While I appreciate his efforts, I think as with the reference change,
this will cause much more widespread pain than we can even imagine.
Without being an expert on this timezone stuff, I suggest to have the
ability to get the old behavior, wether it's reverting to the system
date, either if we can't find the timezone entry, or if that is a
problem due to overlaps, then have a setting which allows to get the
old behavior. I don't even mind if it's called
date.old_broken_timezone_behavior. We did something similar in oci8
in order not to break apps.Andi
At 09:01 AM 9/28/2005, Rasmus Lerdorf wrote:
This discussion has been interesting. ;)
These sorts of problems have come up many times during the course of PHP
development. Things that were implemented to solve a very specific
local problem ended up causing grief when the scope of PHP grew. Think
of things like magic_quotes_gpc and case-insensitive function names.
Both of these actually made perfect sense when they were implemented but
as things got bigger they started to get in the way and today most
people wish we had broken backwards compatibility a long time ago and
gotten rid of those early on.We have tended towards not breaking BC over the years leaving quite a
bit of cruft around for people to deal with. Watching Derick try to
buck that trend has been fun and I think he deserves a bit less vitriol
for his efforts.His new
date()code is obviously better and more portable than what we
had. So it comes down to a pretty simple decision that doesn't need all
that much emotion poured into it:Do we take the BC hit now to get clean and consistent date/time
handling or do we stay with the BC over all else path we usually
take? Either way we have pain. If we break BC there will be plenty
of pain from very vocal users who feel personally wronged that we broke
their code, and if we don't break BC and go with two different
date/time systems we have to live with these two systems forever and
it we will need to hold up the 5.1 release for a couple of weeks.I actually lean more towards the keeping BC side here but was hoping the
new date implementation could get to the point of minimal BC breakage or
perhaps even none with some sort of compatibility mode. I think there
is a lot to be said for not having two different implementations so for
the folks who feel so strongly about this, pitch in with some testing
and help make this new implementation backward compatible. It should be
possible to get this timezone mapping to the point where it addresses
the majority of timezone name overlaps in the world.-Rasmus
--
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/--
--
Donate @ http://pecl.php.net/wishlist.php/sniper
Disclaimer: Donating money may make me happier and friendlier for a limited period!
I completely agree here, and it was only because I was sure that it
was only an implementation and not a functionality change that I
agreed for it to be commited.
We could do something like NIO in Java, and have newr APIs for this
functionality, this way people who want to use the new APIs win (such
as Derick) and old users don't have their applications broken.
Andi
At 05:59 AM 9/29/2005, Wez Furlong wrote:
Call it FUD if you like; I call it "sleeping easier at night". Like
it or not, PHP is big enough now that these things have become
critical points for larger businesses. To completely replace the
default implementation of a core function with something new is quite
a risk when it's not had enough QA. Take a look at Streams for
example; things are still settling down there from their
(embarrasingly buggy) 4.3 debut.You could argue that date/time support in PHP is more critical than
streams, and so changing that worries me more.Whether we intend PHP 5.1 to be a bugfix release or not isn't really
relevant; people will assume that PHP 5.1 is "PHP 5 with some things
fixed and some new things added"... and isn't that really what our
versioning scheme says it will be too?We're a big enough project to have a responsibility
(http://netevil.org/node.php?nid=427) to our users. Progress isn't
about breaking BC at every turn; take a look at the Solaris approach:
innovate by creating new APIs and ensure stability by preserving
existing APIs. This is a solid, reliable approach to software
development, and improves the quality of sleep for us, people
developing applications with PHP, people paying for PHP applications
and for people using those "critical" applications (banking, travel,
auctions).--Wez.
The "masses" don't have to update. The old broken `date()` is still in PHP 4.4.0 and PHP 5.0.x. Please stop the BC fud, this is not about a bugfix release but something a bit bigger thing. One other solution: we can always change PHP_5_1 to PHP_6 and do all other nice "BC" breaks too while we're at it.. And start calling HEAD PHP 7.0 =) --JaniI agree;
date()in 5.1 should default to the older "broken" code for
BC and have a toggle for the new stuff. We could also issue a
deprecation notice to warn people about a future move to the new code
in PHP 6.This way we get the "best" of both worlds; BC is preserved for the
masses of existing code and we get more QA on the new implementation
ready for going production with the new code in PHP 6.--Wez.
When I agreed to commit this for PHP 5.1, Derick promised that this
was going to completely keep BC. That is obviously not happening.
While I appreciate his efforts, I think as with the reference change,
this will cause much more widespread pain than we can even imagine.
Without being an expert on this timezone stuff, I suggest to have the
ability to get the old behavior, wether it's reverting to the system
date, either if we can't find the timezone entry, or if that is a
problem due to overlaps, then have a setting which allows to get the
old behavior. I don't even mind if it's called
date.old_broken_timezone_behavior. We did something similar in oci8
in order not to break apps.Andi
At 09:01 AM 9/28/2005, Rasmus Lerdorf wrote:
This discussion has been interesting. ;)
These sorts of problems have come up many times during the
course of PHP
development. Things that were implemented to solve a very specific
local problem ended up causing grief when the scope of PHP grew. Think
of things like magic_quotes_gpc and case-insensitive function names.
Both of these actually made perfect sense when they were
implemented but
as things got bigger they started to get in the way and today most
people wish we had broken backwards compatibility a long time ago and
gotten rid of those early on.We have tended towards not breaking BC over the years leaving quite a
bit of cruft around for people to deal with. Watching Derick try to
buck that trend has been fun and I think he deserves a bit less vitriol
for his efforts.His new
date()code is obviously better and more portable than what we
had. So it comes down to a pretty simple decision that
doesn't need all
that much emotion poured into it:Do we take the BC hit now to get clean and consistent date/time
handling or do we stay with the BC over all else path we usually
take? Either way we have pain. If we break BC there will be plenty
of pain from very vocal users who feel personally wronged
that we broke
their code, and if we don't break BC and go with two different
date/time systems we have to live with these two systems forever and
it we will need to hold up the 5.1 release for a couple of weeks.I actually lean more towards the keeping BC side here but was
hoping the
new date implementation could get to the point of minimal BC
breakage or
perhaps even none with some sort of compatibility mode. I think there
is a lot to be said for not having two different implementations so for
the folks who feel so strongly about this, pitch in with some testing
and help make this new implementation backward
compatible. It should be
possible to get this timezone mapping to the point where it addresses
the majority of timezone name overlaps in the world.-Rasmus
--
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/--
--
Donate @ http://pecl.php.net/wishlist.php/sniper
Disclaimer: Donating money may make me happier and friendlier for
a limited period!
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/
We know you want to break as many apps as possible, but many of us
prefer to be more accomodating to the large amount of apps out there
and do it in a gradual and controlled way.
For example, with the date(), having a version (such as 5.1.x) which
emits a warning and allows to select old behavior via INI.
At 01:20 AM 9/29/2005, Jani Taskinen wrote:
The "masses" don't have to update. The old broken `date()` is still in PHP 4.4.0 and PHP 5.0.x. Please stop the BC fud, this is not about a bugfix release but something a bit bigger thing. One other solution: we can always change PHP_5_1 to PHP_6 and do all other nice "BC" breaks too while we're at it.. And start calling HEAD PHP 7.0 =) --JaniI agree;
date()in 5.1 should default to the older "broken" code for
BC and have a toggle for the new stuff. We could also issue a
deprecation notice to warn people about a future move to the new code
in PHP 6.This way we get the "best" of both worlds; BC is preserved for the
masses of existing code and we get more QA on the new implementation
ready for going production with the new code in PHP 6.--Wez.
When I agreed to commit this for PHP 5.1, Derick promised that this
was going to completely keep BC. That is obviously not happening.
While I appreciate his efforts, I think as with the reference change,
this will cause much more widespread pain than we can even imagine.
Without being an expert on this timezone stuff, I suggest to have the
ability to get the old behavior, wether it's reverting to the system
date, either if we can't find the timezone entry, or if that is a
problem due to overlaps, then have a setting which allows to get the
old behavior. I don't even mind if it's called
date.old_broken_timezone_behavior. We did something similar in oci8
in order not to break apps.Andi
At 09:01 AM 9/28/2005, Rasmus Lerdorf wrote:
This discussion has been interesting. ;)
These sorts of problems have come up many times during the course of PHP
development. Things that were implemented to solve a very specific
local problem ended up causing grief when the scope of PHP grew. Think
of things like magic_quotes_gpc and case-insensitive function names.
Both of these actually made perfect sense when they were implemented but
as things got bigger they started to get in the way and today most
people wish we had broken backwards compatibility a long time ago and
gotten rid of those early on.We have tended towards not breaking BC over the years leaving quite a
bit of cruft around for people to deal with. Watching Derick try to
buck that trend has been fun and I think he deserves a bit less vitriol
for his efforts.His new
date()code is obviously better and more portable than what we
had. So it comes down to a pretty simple decision that doesn't need all
that much emotion poured into it:Do we take the BC hit now to get clean and consistent date/time
handling or do we stay with the BC over all else path we usually
take? Either way we have pain. If we break BC there will be plenty
of pain from very vocal users who feel personally wronged that we broke
their code, and if we don't break BC and go with two different
date/time systems we have to live with these two systems forever and
it we will need to hold up the 5.1 release for a couple of weeks.I actually lean more towards the keeping BC side here but was hoping the
new date implementation could get to the point of minimal BC breakage or
perhaps even none with some sort of compatibility mode. I think there
is a lot to be said for not having two different implementations so for
the folks who feel so strongly about this, pitch in with some testing
and help make this new implementation backward compatible. It should be
possible to get this timezone mapping to the point where it addresses
the majority of timezone name overlaps in the world.-Rasmus
--
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/--
--
Donate @ http://pecl.php.net/wishlist.php/sniper
Disclaimer: Donating money may make me happier and friendlier for a
limited period!
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/
When I agreed to commit this for PHP 5.1, Derick promised that this was going
to completely keep BC. That is obviously not happening. While I appreciate his
efforts, I think as with the reference change, this will cause much more
widespread pain than we can even imagine.
Uhm, the stuff that we agreed to commit has nothing to do with this, as
it's still disabled just fine.
regards,
Derick
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Quick check so I completely understand where we are:
- In Israel the timezone DB changes every year (we start savings time
on different dates every year depending on the parliament decision).
I see that in your implementation this DB is taken from a table
written in C. Are you saying that this table isn't currently being
used? Or would I have to update that C table every year?
All sysadmins in Israel pretty much have an automated way of getting
the updated timezone file from a central distribution FTP server
which they just drop in automatically into the system. Not allowing
this to work would be a serious problem. Israel's probably not the
only country with a dynamically changing DB. Also, it would require
us to roll new PHP versions whenever such a company changes their DB.
So if this is the case, irregardless we should support the old approach.
Anyway, please give some more insight so that the situation is clear.
As stated in my previous email, irregardless, as Wez pointed out
having two sets of APIs is probably a better idea so that everyone is happy.
Thanks,
Andi
At 12:13 AM 9/29/2005, you wrote:
When I agreed to commit this for PHP 5.1, Derick promised that
this was going
to completely keep BC. That is obviously not happening. While I
appreciate his
efforts, I think as with the reference change, this will cause much more
widespread pain than we can even imagine.Uhm, the stuff that we agreed to commit has nothing to do with this, as
it's still disabled just fine.regards,
DerickDerick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Zend/PHP Conference & Expo
Power Your Business with PHP
October 18-21, 2005 - San Francisco
http://zend.kbconferences.com/
- In Israel the timezone DB changes every year (we start savings time on
different dates every year depending on the parliament decision).
That is incorrect. That was only upto and including 2004. Since 2005
there is a set-rule for it.
I see that
in your implementation this DB is taken from a table written in C. Are you
saying that this table isn't currently being used? Or would I have to update
that C table every year?
Ofcourse the table is in use, otherwise it would not have been put in.
All sysadmins in Israel pretty much have an automated way of getting the
updated timezone file from a central distribution FTP server which they just
drop in automatically into the system. Not allowing this to work would be a
serious problem. Israel's probably not the only country with a dynamically
changing DB.
Brasil is AFAIK the only other one.
Also, it would require us to roll new PHP versions whenever such
a company changes their DB. So if this is the case, irregardless we should
support the old approach.
Or we create a PECL extension that you can install and if it is
installed then it uses the timezone database from there. And yes,
ofcourse I keep updating the timezone database in CVS as soon as a new
one is out.
Anyway, please give some more insight so that the situation is clear.
As stated in my previous email, irregardless, as Wez pointed out having two
sets of APIs is probably a better idea so that everyone is happy.
That also means that we're reintroducing about a 20 bugs again. Please
remember that the whole idea why I started with it was that the code
now is broken, even although it might seem to work fine for you.
regards,
Derick
20 known (and worked-around) bugs are "better" than an unknown
quantity of unknown bugs.
Remember: it worked "yesterday" but with the minor release it stops working.
Just because the new version works for you, doesn't mean it isn't
broken for others :)
Can you honestly guarantee that it's not going to be a BC break by the
time we release?
Are you really sure it's worth risking the stability of so many apps?
--Wez.
Anyway, please give some more insight so that the situation is clear.
As stated in my previous email, irregardless, as Wez pointed out having two
sets of APIs is probably a better idea so that everyone is happy.That also means that we're reintroducing about a 20 bugs again. Please
remember that the whole idea why I started with it was that the code
now is broken, even although it might seem to work fine for you.
20 known (and worked-around) bugs are "better" than an unknown
quantity of unknown bugs.Remember: it worked "yesterday" but with the minor release it stops working.
Just because the new version works for you, doesn't mean it isn't
broken for others :)Can you honestly guarantee that it's not going to be a BC break by the
time we release?
Well, it would be much better if we just force people to set the setting
correctly, then it doesn't break any BC. And ofcourse, you can never
guarantee anything for a 100%, but it definitely should cover things
for a large majority. I do think we should not be saying
"oooh, it doesn't work - let's remove it and go back to "working" code,
which is broken. Also, if it does gets guessed wrong, all you need to
do is set one php.ini setting. If this was a .0.x release then this is a
problem, but not when you're bumping from 5.0 to 5.1.
regards,
Derick
On Wed, 28 Sep 2005 09:01:12 -0700
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:
This discussion has been interesting. ;)
These sorts of problems have come up many times during the course of
PHP development. Things that were implemented to solve a very
specific local problem ended up causing grief when the scope of PHP
grew. Think of things like magic_quotes_gpc and case-insensitive
function names. Both of these actually made perfect sense when they
were implemented but as things got bigger they started to get in the
way and today most people wish we had broken backwards compatibility
a long time ago and gotten rid of those early on.
Except that one should listen to valid concerns and not commit anything
to a feature freezed branche. Sorry to say it again and again, but I'm
really pissed off by this attitude.
We have tended towards not breaking BC over the years leaving quite a
bit of cruft around for people to deal with. Watching Derick try to
buck that trend has been fun and I think he deserves a bit less
vitriol for his efforts.
I prefer some ears vacuum cleaner.
I actually lean more towards the keeping BC side here but was hoping
the new date implementation could get to the point of minimal BC
breakage or perhaps even none with some sort of compatibility mode.
I think there is a lot to be said for not having two different
implementations so for the folks who feel so strongly about this,
pitch in with some testing and help make this new implementation
backward compatible. It should be possible to get this timezone
mapping to the point where it addresses the majority of timezone name
overlaps in the world.
The problem is to prevent the points of failures, to provide a BC fix
for each of them. It could be possible if we have a way to tests and
compare the 4.x - 5.0.x behaviors with Derick implementations, but we
have nothing but a huge amount of suppositions.
As I said, I doubt we can delay again 5.1.0 for some more weeks. Unless
we drop all the Derick's changes and restore the previous codes, I
doubt we have enough time to find a valid solution or implement any
fancy tags.
--Pierre
It looks like all become relaxed now here but not me.
Here in Israel, there is stupid habit to change the DST range almost each
year.
Should i expect that today's php5.1 date() function 'll give me wrong date
next year?
If yes, we have here fatal BC break since modern server OS DST data is
automatically refreshed, but
out of the question the php version on my servers .... the only reasonable
solution is separated set of functions as Pierre proposed.
Moshe
"Derick Rethans" derick@php.net wrote in message
news:Pine.LNX.4.62.0509281552110.24804@localhost...
DR>>> too because it concides with Fiji and Austria and your Db doesn't
support
DR>>> it?
DR>>
DR>>I don't see your point here, can you clarify this with a little
example
DR>>perhaps?Well, that's the same problem I had but it would be not IDT, but, say,
some FDT which has multiple timezones too. Now if you say it would be
generated from some big TZ database and not just fixed for particular
case then I guess it would not be a concern.Right, of course fixing it for IDT only would be silly :)
regards,
Derick--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
On Wed, 28 Sep 2005 15:59:45 +0300 (IDT)
stas@zend.com (Stanislav Malyshev) wrote:
DR>>I think this shoul adequately solve the problems that you
DR>>encountered.Thanks for finding a way to solve it at least for this example. But I
am still concerned that it would solve the problem for me, but what
if I install it somewhere in Finland or Australia and their TZ is not
working too because it concides with Fiji and Austria and your Db
doesn't support it? Though if the algorithm takes also GMT offset
into account it may work (unless we have two TZs with same
abbreviation, same current settings but different rules - I don't
know if such beasts exist).
There is no safe solution but using a separate set of functions until
6.0. I tried too many times to explain how complex can be date/time
problems and trying to fix them in a minor release is the best bad idea
of the year.
--Pierre
Pierre wrote:
There is no safe solution but using a separate set of functions until
6.0. I tried too many times to explain how complex can be date/time
problems and trying to fix them in a minor release is the best bad idea
of the year.
I'm with you on that, but since UNICODE is now becoming my major
stumbling block perhaps I should just stick with PHP5.0.4 until PHP6 is
available the same as most people seem to be staying with PHP4.3 ;)
--
Lester Caine
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
hmm but if Derick's picking up the name of the tz the way he suggested and
printing it as part of an E_STRICT we'll soon get clear reports of any
exceptions to the rule.
----- Original Message -----
From: "Stanislav Malyshev" stas@zend.com
To: "Derick Rethans" derick@php.net
Cc: "PHP Developers Mailing List" internals@lists.php.net
Sent: Wednesday, September 28, 2005 1:59 PM
Subject: Re: [PHP-DEV] timezones & date() breakage
DR>>I think this shoul adequately solve the problems that you encountered.
Thanks for finding a way to solve it at least for this example. But I am
still concerned that it would solve the problem for me, but what if I
install it somewhere in Finland or Australia and their TZ is not working
too because it concides with Fiji and Austria and your Db doesn't support
it? Though if the algorithm takes also GMT offset into account it may work
(unless we have two TZs with same abbreviation, same current settings but
different rules - I don't know if such beasts exist).--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
I wouldn't call it broken, just less inituitive. But besides that point,
I looked at some data and have a patch that allows the timezone guessing
code to also check against the GMT offset, and not only the
abbreviation. This means that with these DB entries:{ "idt", 1, -HOUR ( 3), "Asia/Tel_Aviv" }, { "idt", 1, -HOUR (4.5), "Iran/Teheran" }, { "idt", 1, -HOUR (6.5), "Asia/Calcutta" },IDT will be recognised correctly for all three variations.
Cool, you can generate a sane E_STRICT from that too (telling people what
they need in their php.ini to speed things up).
I wouldn't call it broken, just less inituitive. But besides that point,
I looked at some data and have a patch that allows the timezone guessing
code to also check against the GMT offset, and not only the
abbreviation. This means that with these DB entries:{ "idt", 1, -HOUR ( 3), "Asia/Tel_Aviv" }, { "idt", 1, -HOUR (4.5), "Iran/Teheran" }, { "idt", 1, -HOUR (6.5), "Asia/Calcutta" },IDT will be recognised correctly for all three variations.
Cool, you can generate a sane
E_STRICTfrom that too (telling people what
they need in their php.ini to speed things up).
It already does that:
Strict standards: `date()`: It is not safe to rely on the systems
timezone settings, please use the date.timezone setting, the TZ
environment variable or the `date_default_timezone_set()`
function. We use 'Europe/Berlin' for 'CEST/2.0' instead. in
Command line code on line 1
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Derick Rethans wrote:
LC>>> UTC. Do you have your watch in UTC and your wall clock in your home in
LC>>> UTC?
LC>>
LC>>ACTUALLY - all the server clocks are set to GMT - that way I know who ever
LC>>enters data, the timestamp is always correct, what ever their local time ;)I am starting to get an impression that you reply to me without reading
what I wrote. Once more: when I need to display current time for this
machine, I don't need UTC.But you do need UTC somewhere, as all date code (OS, applications)
use UTC timestamps to calculate the current time.
And I have finally found the hole in what I am trying to do - as it
was hidden in someone else's code ;)
the javascript getTimezoneOffset() only gives the current time offset
from UTC and requests for daylight saving information with it go back to
at least 2001 :(
So I will have to continue with asking a user where they are when they
log in ;)
Stanislav - DISPLAYING local time only applies to the local site - when
you are logging into an Australian machine the local time of that
machine is not a lot of use. But IF I want to compare - say - bid
times between an American and an Australian machine, then the ONLY time
that can be used is UTC ?
--
Lester Caine
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
LC>>Stanislav - DISPLAYING local time only applies to the local site - when you
LC>>are logging into an Australian machine the local time of that machine is not
LC>>a lot of use. But IF I want to compare - say - bid times between an
Just think about what you are telling me. I say "with new code my
application stopped working" and you answer me "but if you application
would do something completely different that it never intended to do, the
new code enables it to do it". What kind of answer is that? Yes, for your
application it is necessary to display time local for the client - but for
MY application it is NOT! Is it so hard to understand?
If you want to do your stuff - fine, do it (if you can - think about
where are you going to find updated timezone rules in format PHP needs and
how easy would it be for you to put them in PHP?). I am talking about
something different - about MY stuff that stopped working, and according
to what Derick says would never work again.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
Stanislav Malyshev wrote:
LC>>Stanislav - DISPLAYING local time only applies to the local site - when you
LC>>are logging into an Australian machine the local time of that machine is not
LC>>a lot of use. But IF I want to compare - say - bid times between anJust think about what you are telling me. I say "with new code my
application stopped working" and you answer me "but if you application
would do something completely different that it never intended to do, the
new code enables it to do it". What kind of answer is that? Yes, for your
application it is necessary to display time local for the client - but for
MY application it is NOT! Is it so hard to understand?
If you want to do your stuff - fine, do it (if you can - think about
where are you going to find updated timezone rules in format PHP needs and
how easy would it be for you to put them in PHP?). I am talking about
something different - about MY stuff that stopped working, and according
to what Derick says would never work again.
I'm with you on NOT breaking perfectly working code. We have already had
that enough fun with PHP4.4.0 and PHP5.0.5 - WARN don't break!
I am not arguing about what is different between 5.0 and 5.1 - as far as
I am concerned nothing should change. UNLESS I ask for new facilities
( and I need them in Windows - not a compile switch !! ) the old code
should work - with warnings. The problem I see is that people ARE only
looking at their view of things rather than a clean global picture?
MY problem is getting the new stuff to actually give me the correct
information, and I'm not sure that it does until I can test it - THEN we
have to convince people to actually CHANGE to PHP5.1 !!! Something that
has not happened yet :( and will mean that in order to deploy
applications we are hamstrung by relying on a particular version of PHP
Personally I would prefer a TIMESTAMP with separate date and time rather
than these epoch integers. I'm convinced that would give better
performance in a lot of areas especially when interfacing with database
DATE/TIME/TIMESTAMP and processing things like GROUP BY DAY/MONTH - but
there again in other areas seconds help. When you are building genealogy
data the time is of little use so a pure date is more appropriate - back
several thousand years - but selecting the right calendar is another
problem ;)
--
Lester Caine
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
Derick Rethans wrote:
I'm coming in late here - but being in the middle of trying to configure a
system to provide calendars across time and daylight saving zones, I've
been deep in this! I have no problem with the time AT THE SERVER! What I
need to know is what daylight saving zone the client is in so I can build
the correct calendar for March/April or October/November. ALL the data on
the server is stored UTC so I could not care less which zone it is in :)
The ONLY solution I currently have is to get the client to set their
time/daylight zone in their profile on the server ?I've no clue what you mean here... sorry. Try to explain a bit better what
you want to do. Do you want to render events' dates with the correct
timezone while your data is in UTC (as Unix timestamp?)?Yes
Client currently supplies tz_offset, but that does not identify the daylight
saving offset so you can not show the correct shifts of calendar times for the
'other' daylight offset :(
So let him specify the area in which he is in, then you can use the
correct timezone identifier for it. This is what the new code now allows
you to do, which should make things much easier for you. I'll see if I
can get the list of supported identifiers in the manual, as for PHP
5.1.0 the previously mentioned timezone_identifiers_list() is not
enabled here yet. For information on how to use things, see this
presentation:
http://derickrethans.nl/files/time-ac2005.pdf
The FIRST problem I had was STOPPING the display from being offset by the
SERVER daylight saving setting!
There is absolutely no reason thatdate()should supply anything other than
the current UTC time. It is the only thing that is actually RIGHT!
gmdate() is for that, date() should always show a local time. The new
code (which is unfortunately not enabled), allows you do do all kinds of
timezone manipulation. Feel free to test it by setting your CFLAGS to
-DEXPERIMENTAL_DATE_SUPPORT and use the new functions following the
examples from the presentation.
regards,
Derick
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Derick Rethans wrote:
gmdate()is for that,date()should always show a local time. The new
Local to who ;)
code (which is unfortunately not enabled), allows you do do all kinds of
timezone manipulation. Feel free to test it by setting your CFLAGS to
-DEXPERIMENTAL_DATE_SUPPORT and use the new functions following the
examples from the presentation.
I am building a calendar that requires the correct daylight saving
entries historically and ongoing. Will the new system support this or is
it purely designed to provide the current daylight saving setting -
which most sources I've tried to access seem to be limited to?
Providing a correct ongoing clock is one thing, but does not address the
real problem with timezones and daylight saving. When did they start,
what calendar do they follow, which setting do I use for - say - 2000 ?
Fortunately I have already stripped the date()/time() raw entries from
bitweaver and it uses getUTCTime() which means that only one routine
needs managing. Then the display routine works off the CLIENT selection
of time/daylight saving ;)
I just have not been able to correct the display of the CLIENT selection
for the calendar yet :(
--
Lester Caine
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
Derick Rethans wrote:
gmdate()is for that,date()should always show a local time. The new
Local to who ;)code (which is unfortunately not enabled), allows you do do all kinds of
timezone manipulation. Feel free to test it by setting your CFLAGS to
-DEXPERIMENTAL_DATE_SUPPORT and use the new functions following the examples
from the presentation.
I am building a calendar that requires the correct daylight saving entries
historically and ongoing. Will the new system support this or is it purely
designed to provide the current daylight saving setting - which most sources
I've tried to access seem to be limited to?
It should do it for historical data too, but that data might not always
be available - the database that I'm using does have a lot of
information though.
Providing a correct ongoing clock is one thing, but does not address the real
problem with timezones and daylight saving. When did they start, what calendar
do they follow, which setting do I use for - say - 2000 ?
You don't have to care about that, as you simply set the location
(Europe/Oslo f.e.) and the date code can format according to that.
Fortunately I have already stripped the date()/time() raw entries from
bitweaver and it uses getUTCTime() which means that only one routine
needs managing.
What's wrong with time(), that should always return the current time in
GMT/UTC (if the server's time is correct ofcourse).
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Derick Rethans wrote:
I am building a calendar that requires the correct daylight saving entries
historically and ongoing. Will the new system support this or is it purely
designed to provide the current daylight saving setting - which most sources
I've tried to access seem to be limited to?It should do it for historical data too, but that data might not always
be available - the database that I'm using does have a lot of
information though.
I've got some things to check against ;)
Not sure I spotted your source of data?
Providing a correct ongoing clock is one thing, but does not address the real
problem with timezones and daylight saving. When did they start, what calendar
do they follow, which setting do I use for - say - 2000 ?You don't have to care about that, as you simply set the location
(Europe/Oslo f.e.) and the date code can format according to that.
Need to know how to adjust the calendar display around the daylight
saving change! The 25 hour day and the 23 Hour day - it would be nice to
highlight them for the view you are creating, especially when you are
planning round the working hours restrictions ;)
Fortunately I have already stripped the
date()/time() raw entries from
bitweaver and it uses getUTCTime() which means that only one routine
needs managing.What's wrong with
time(), that should always return the current time in
GMT/UTC (if the server's time is correct ofcourse).
Originally it was, but while unix epochs look the best solution, having
real timestamps that can be filtered/grouped/counted on dates without
having to process every integer in the database - depending on which
database engine you are using ....
THAT particular 'crap performance' has still to be addressed :(
--
Lester Caine
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.
Derick Rethans wrote:
I am building a calendar that requires the correct daylight saving entries
historically and ongoing. Will the new system support this or is it purely
designed to provide the current daylight saving setting - which most
sources
I've tried to access seem to be limited to?It should do it for historical data too, but that data might not always be
available - the database that I'm using does have a lot of information
though.
I've got some things to check against ;)
Not sure I spotted your source of data?
timezone_transistions_get() in the new date/time support code.
Derick
DR>>Using a timezone abbreviation is a bad thing anyway. Your timezone is
Breaking working applications is a bad thing.
DR>>"Isreal/Tel Aviv" and currently your abbreviation is IDT. IDT is not a
DR>>timezone, it is the description of the period in which you use DST in
DR>>combination with Israel time.
So, in order for my application to continue working I should go and try to
find out the incantation that your library will agree to accept, right?
And if I don't find one, bad luck - no date() anymore. So how that's an
improvement? Can I get back the unimproved working one?
DR>>As I already said, no, it does not use the OS's timezone database for
DR>>the obvious reasons mentioned.
You didn't mention any "obvious reasons", however.
DR>>The timezone database that I use is updated from the respected Olson
DR>>database. All distributions use this (and I hope also Windows). If the
DR>>distributions don't, then their information is incorrect and not
DR>>PHP's. This is one of the reasons why we have our own database.
See, if my system works correctly with times (meaning, computer clock
shows the same time that the clock on my desk is showing and the clock on
the reailway station is showing) and with your database it's wrong - I
couldn't care less how "respected" it is. And this is bound to happen if
you don't use system's rules, since some rules change and you would have
serious problems keeping them up-to-date - not to mention I would have to
reinstall PHP in order to get your fixes.
DR>>But they are totally crippled. Timezone abbreviations are not unique
As for now, PHP is totally crippled for me - I can't use date() unless I
guess what your library want from me. And now imagine I want to install
this application on user's system - now I'd have to guess what magic
incantation your library wants me to use on HIS system - without any help
from your library, of course, it would just refuse to work until I find
out the right one. So, what do you propose me to do in this case?
DR>>this ourselves - the only thing is that you actually have to specify
DR>>your timezone in your php.ini file now.
I have my timezone perfectly well in the system, and all other
applications except PHP are just fine with it - how comes only PHP needs
special handling?
DR>> date.timezone string
DR>>
DR>> The default timezone used by all date/time functions if the TZ
DR>> environment variable isn't set. The precedence order is described in the
DR>> date_default_timezone_get() page.
So, where does it say what I should write there? Obviously, not what
system 'date' command returns. But what? Where can I take the "real and
true" name that your library wants? Why it just can't take it where the
rest of applications running on my system and never having any problems
with timezones take it?
DR>>The one that the C code recognizes is already a fallback in case you
DR>>don't set this setting. You don't need to change any C code in order to
DR>>pick the correct timezone. (And for you you should use "Asia/Tel_Aviv"
DR>>as setting).
How did you find that out? Where it is documented that I should use this
name and can't use any other? What should I do when I install my app on
client's site to find out what he has to use?
Do you understand it's not a problem that I can't run something on my
particular system after asking you but that the whole functionality block
is broken and now needs rewriting in every appication out there that uses
date()? And that it needs different fixes for each particular install of
the app? Do you think it's OK?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
So, in order for my application to continue working I should go and try to
find out the incantation that your library will agree to accept, right?
And if I don't find one, bad luck - nodate()anymore. So how that's an
improvement? Can I get back the unimproved working one?
Please keep all the sarcasm for yourself.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
DR>>> find out the incantation that your library will agree to accept, right?
DR>>> And if I don't find one, bad luck - no date() anymore. So how that's an
DR>>> improvement? Can I get back the unimproved working one?
DR>>
DR>>Please keep all the sarcasm for yourself.
There's no any sarcasm - I really do want date() to work like it did
before. It is OK to give additional capability for timezone changing, etc.
- but I don't see why this should be at the cost of making previously
working code now require additional configuration that - as it seems - can
not even be done automatically, since the configuration value is not
present anywhere in the system settings.
I propose to make some mode to date() that would allow falling back to old
functionality if I do not use new improved capabilities. Meaning, if I do
not set new configurations, it would work as it did in PHP4. Is this
possible?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
There's no any sarcasm - I really do want
date()to work like it did
before. It is OK to give additional capability for timezone changing, etc.
- but I don't see why this should be at the cost of making previously
working code now require additional configuration that - as it seems - can
not even be done automatically, since the configuration value is not
present anywhere in the system settings.
That's the reason why we try to guess it - which works often, but not in
your case with IDT.
I propose to make some mode to
date()that would allow falling back to old
functionality if I do not use new improved capabilities. Meaning, if I do
not set new configurations, it would work as it did in PHP4. Is this
possible?
Not really. You really do need to make the configuration setting as none
of the code currently relies on any OS, and we should definitely keep it
like that. Now, what we can do is document the list of setttings that
you can use as timezone.
regards,
Derick
DR>>Not really. You really do need to make the configuration setting as
DR>>none of the code currently relies on any OS, and we should definitely
DR>>keep it like that. Now, what we can do is document the list of
DR>>setttings that you can use as timezone.
The problem is I don't think there's even a place in the system that
contains the value you want, let alone standard place. Which means, this
configuration process is impossible to automate, which means, basically,
that any app using date() can not be run on 5.1 without sysadmin manually
reconfiguring PHP. I can not see why it should be the case, and I can not
see why you can not use old code in such situation.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
I propose to make some mode to
date()that would allow falling back to old
functionality if I do not use new improved capabilities. Meaning, if I do
not set new configurations, it would work as it did in PHP4. Is this
possible?
Yeah, keep using PHP 4.
--Jani
JT>> Yeah, keep using PHP 4.
That's an excellent suggestion. Thank you very much.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
Stanislav Malyshev wrote:
DR>>Using a timezone abbreviation is a bad thing anyway. Your timezone is
Breaking working applications is a bad thing.
DR>>"Isreal/Tel Aviv" and currently your abbreviation is IDT. IDT is not a
DR>>timezone, it is the description of the period in which you use DST in
DR>>combination with Israel time.So, in order for my application to continue working I should go and try to
find out the incantation that your library will agree to accept, right?
And if I don't find one, bad luck - nodate()anymore. So how that's an
improvement? Can I get back the unimproved working one?
This "incantation" is the standard name for your timezone across most
systems. Out of curiosity I've just tried "IDT" timezone on 3 machines
(Linux, FreeBSD and OpenSolaris) neither of'em supported it. However,
they all supported "Israel/Tel Aviv", which is the real name for your
timezone.
The bundled timezones Derick provides ensure that there is a constant
list of available timezones that is always available. On many systems
the full list was simply not compiled, so you simply cannot change the
TZ period. With the new change this is once again possible.
Ilia
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", 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.
Provided that date() worked fine before, I see absolutely no reason to
require such complex things now - for doing the same basic things as
before. If you need to do andavnced things - that's OK, require advanced
configuration, but simple things should be kept simple and work with
defaults as they did before.
IA>>The bundled timezones Derick provides ensure that there is a constant
IA>>list of available timezones that is always available. On many systems
IA>>the full list was simply not compiled, so you simply cannot change the
IA>>TZ period. With the new change this is once again possible.
What I am concerned here is not what is possible with new system - it's
all fine it is so advanced and I am sure it allows to do a lot of good and
necessary stuff. What I am concerned with is what is NOT possible with it
- e.g., taking application working just fine on 5.0 and running it or
installing a new application on it iwthout having the user to jump trrough
a lot of hoops. And telling the user "you know, you have to configure your
timezone setting, and no, we can't tell you what to write there - you have
to find out 'real name' by yourself because it is not present on your
system anywhere" is not going to be a good solution for an application. So
can you provide the good solution here - namely, how do I know a "real
name" of the current timezone from PHP?
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.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
Stas,
The problem before was that there was no 1 certain date setting. For
example on your machine IDT worked, on mine "Israel/Tel Aviv" and for
Derick Asia/Tel_Aviv was the working name for the same timezone. So when
designing an app to run on different servers the developer will have to
find out all these different names for the same thing.
With the date extension there is one unchanging list (even for win32
users) that will always be constant. So once you determine the desired
timezone name you use it without being concerned about system's TZ settings.
Yes, initially there will be some short-term pain in converting existing
apps, but for the long term it'll provide a robust and portable
solution. If we add "legacy" flag or INI setting, I feel that we'd be
taking a step backwards in terms of making applications portable.
Ilia
Yes, initially there will be some short-term pain in converting existing
apps, but for the long term it'll provide a robust and portable
solution. If we add "legacy" flag or INI setting, I feel that we'd be
taking a step backwards in terms of making applications portable.
Such a legacy flag is not even possible without redoing all of the code
by crippling it. There is no way that that is going to happen.
Derick
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
IA>>The problem before was that there was no 1 certain date setting. For
Oh, but there is. It is "use system settings". That is the date setting I
am looking for, and that's what I will be using in 99% of the cases -
because apps I dela with don't need multiple timezone support on single
server - they just need to say "this happened on so-and-so time on this
server" - and that's it.
IA>>With the date extension there is one unchanging list (even for win32
IA>>users) that will always be constant. So once you determine the desired
IA>>timezone name you use it without being concerned about system's TZ settings.
But I want to be concerned about system's TZ settings - I want to use
exactly the same time system is using. And I did it happily before. Why
can't I do now? I don't ask you to drop functions you need - I ask you
not to drop the function I needd - and probably a lot of other people
that are going to discover it once they install 5.1 would need, only they
would find it out too late to fix it in 5.1.
IA>>Yes, initially there will be some short-term pain in converting existing
IA>>apps, but for the long term it'll provide a robust and portable
It's not "short-term pain" - I see no way to convert any app to work with
this mechanism for 5.1 at all, since this setting is not possible to
discover from the app.
IA>>solution. If we add "legacy" flag or INI setting, I feel that we'd be
IA>>taking a step backwards in terms of making applications portable.
I don't see why making application portable requires to break
already perfectly portable application. And I, personally, don't think
making the user manually configure each install of the app is a
portability as I see it, BTW.
If you for some reason which I can not understand can not make date() be
compatible with old settings - ok, add system_date() then which would
work as the old date(). Then at least there would be a way to run it on
5.1 in a portable way.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
On Tue, 27 Sep 2005 09:58:11 -0400
ilia@prohost.org (Ilia Alshanetsky) wrote:
Yes, initially there will be some short-term pain in converting
existing apps, but for the long term it'll provide a robust and
portable solution. If we add "legacy" flag or INI setting, I feel
that we'd be taking a step backwards in terms of making applications
portable.
The only problem being to "break" things between 5.0 and 5.1. The
ext/date should have been a separate extension without touching the
existing code based. This way allowed to provide rock solid and
portable solutions and keeps BC with all working applications.
This was what I said for months without too much success. This was even
our plan to add pecl/date as ext/date in 5.1 but Derick thought it is
better to go this way, so it goes...
--Pierre
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 usedate()- or application usingdate()-
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
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
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 functiontimezone_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?
You are perhaps not aware that the timezone databases on many servers
are so incredibly out of date, are you? And your "system settings" are
not working, read the mails once more why. I am not going to repeat it
again.
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.pdfI 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 rundate()and get my
systems date - now I can't.
Correct - as the code was totally inadequate for the tasks. I know you
prefer to live with old crippled code for as long as possible, but you
do forget that there are people who are actually need the new improve
behavior. I did my best to make it as BC as possible, but I can't cover
all the cases. So I guess your options are to stick with an old PHP
version, or change one setting in your php.ini file for the cases
where PHP doesn't guess your timezone correctly. It is impossible to
hack in the old behavior into the new code, if you want to know why -
read the code.
regards,
Derick
DR>>You are perhaps not aware that the timezone databases on many servers
DR>>are so incredibly out of date, are you? And your "system settings" are
DR>>not working, read the mails once more why. I am not going to repeat it
DR>>again.
My settings are working perfectly well, thank you. All and every
application besides PHP 5.1 can use them and display date correctly.
The only application that can not display date correctly without
additional configuration is PHP 5.1. Why?
DR>>Correct - as the code was totally inadequate for the tasks. I know you
It was adequate for the task of displaying current date. Now it is not.
DR>>prefer to live with old crippled code for as long as possible, but you
DR>>do forget that there are people who are actually need the new improve
DR>>behavior. I did my best to make it as BC as possible, but I can't cover
I have nothing against having new and improved behaviour. Use it as much
as you wish. Only thing I need is to be able to use old behaviour too.
Especially that I suspect that the majority of the use cases for
date() would be happy with the old behaviour.
DR>> version, or change one setting in your php.ini file for the cases
As I already explained, the problem is not setting it on my personal
php.ini. The problem is that it makes impossible to port applications
between different servers without having each server pre-configured with
right settings - and these settings are not discoverable by automatic
means. Meaning, each application would either have user to set up timezone
on install (provided the user knows it - many don't know exact name of
their timezone and just use whatever configured on the system) manually -
or display wrong dates.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115