Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » timezones & date() breakage »

timezones & date() breakage

php.internals

Stanislav Malyshev

20 years ago
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

Derick Rethans

20 years ago
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
> 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 > all date() 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

Stanislav Malyshev

20 years ago
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

Derick Rethans

20 years ago
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
> 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_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?
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

Lester Caine

20 years ago
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.

Derick Rethans

20 years ago
On Tue, 27 Sep 2005, Lester Caine 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?)? Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Lester Caine

20 years ago
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.

Stanislav Malyshev

20 years ago
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

Lester Caine

20 years ago
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.

Stanislav Malyshev

20 years ago
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

Derick Rethans

20 years ago
On Tue, 27 Sep 2005, Lester Caine wrote:
> 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 that date() 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

Lester Caine

20 years ago
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

20 years ago
On Tue, 27 Sep 2005, Lester Caine wrote:
> 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

Stanislav Malyshev

20 years ago
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

Derick Rethans

20 years ago
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
> 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?
Please keep all the sarcasm for yourself. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Stanislav Malyshev

20 years ago
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

Derick Rethans

20 years ago
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
> 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

Stanislav Malyshev

20 years ago
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

Jani Taskinen

20 years ago
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
> 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

Stanislav Malyshev

20 years ago
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

Ilia A.

20 years ago
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 - no date() 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

Stanislav Malyshev

20 years ago
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

Ilia A.

20 years ago
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

Derick Rethans

20 years ago
On Tue, 27 Sep 2005, 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.
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

Stanislav Malyshev

20 years ago
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

Pierre-Alain Joye

20 years ago
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

Derick Rethans

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

Stanislav Malyshev

20 years ago
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

Derick Rethans

20 years ago
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
> 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?
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.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.
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

Zeev Suraski

20 years ago
At 16:49 27/09/2005, Stanislav Malyshev wrote:
>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.
I completely agree. So far, except for meaningless purism, I haven't seen a single real reason for the fact that a working application suddenly stopped working. The old code didn't have IDT hardcoded, therefore all of the sarcasm and cynicism around the validy of the code are completely baseless. It was using a system setting, which I suspect a lot of applications will. The fact date() now tries to be intelligent about it but fail is a real problem. Zeev

Peter Brodersen

20 years ago
On Wed, 28 Sep 2005 00:08:37 +0300, in php.internals zeev@zend.com (Zeev Suraski) wrote:
>The old code didn't have IDT hardcoded, therefore all of the sarcasm and >cynicism around the validy of the code are completely baseless. It was >using a system setting, which I suspect a lot of applications will. The >fact date() now tries to be intelligent about it but fail is a real problem.
Just out of curiousity of the scope of this issue... where did the string "IDT" come from in the first place? Any specific distribution? Default OS setting?
-- - Peter Brodersen

Stanislav Malyshev

20 years ago
PB>>Just out of curiousity of the scope of this issue... where did the PB>>string "IDT" come from in the first place? That's what I see as a timezone what I run 'date' from command line.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Derick Rethans

20 years ago
On Wed, 28 Sep 2005, Stanislav Malyshev wrote:
> PB>>Just out of curiousity of the scope of this issue... where did the > PB>>string "IDT" come from in the first place? > > That's what I see as a timezone what I run 'date' from command line.
It's also what you would see in India right now - and they mean two totally different things. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Derick Rethans

20 years ago
On Wed, 28 Sep 2005, Zeev Suraski wrote:
> So far, except for meaningless purism, I haven't seen a single real > reason for the fact that a working application suddenly stopped > working.
I'm quite tired of this purism argument. You seem to invoke that whenever somebody wants to make some form of progress. Now, besides the whining and bickering, if you have any idea on how to make things better, please step forward. I already spoke with the doc folks how to document all the timezones that we now support. Now, the reason that IDT is currently not in the list is because the old strtotime() code already use IST (Indian Standard Time) - which is also used for Israel Standard Time. As you can see, there is a conflict here. As the original code already used it for Indian time, we can not change that now. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Stanislav Malyshev

20 years ago
DR>>Now, besides the whining and bickering, if you have any idea on how to DR>>make things better, please step forward. I already spoke with the doc Yes, I have an idea. Restore old date() function while keeping new one.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Pierre-Alain Joye

20 years ago
On Wed, 28 Sep 2005 09:37:14 +0200 (CEST) derick@php.net (Derick Rethans) wrote:
> On Wed, 28 Sep 2005, Zeev Suraski wrote: > > > So far, except for meaningless purism, I haven't seen a single real > > reason for the fact that a working application suddenly stopped > > working. > > I'm quite tired of this purism argument. You seem to invoke that > whenever somebody wants to make some form of progress.
Your definition of progress may be different than mine, why am I forced to support yours?
> Now, besides the whining and bickering,
Are you trying again to define valid complaints as whining?
> if you have any idea on how to make things better, please step > forward. I already spoke with the doc folks how to document all the > timezones that we now support.
I had better and safer solutions, you ignored my initial proposal to do not touch the current code base and use ext/date with pecl/date. You even moved your code to ext/date and replace all current implementation, blocking any valid alternative. Again and for the record in this thread, I told you and here many times, the only safe way is to develop the new features in a separate code base (ext/date was planned to be used for this exact purpose before you decided to move your code there). A separate code base is the only way to keep user codes working. Whether user codes were good or bad is not relevant as they worked and there was not valid alternative in the PHP releases. As a side note, you should ban STFU, whining, and other related words from your vocabulary, at least in the next 20 years. They do not have their places here, not the way and where you use them. Regards, --Pierre

Ron Korving

20 years ago
> Again and for the record in this thread, I told you and here many > times, the only safe way is to develop the new features in a separate > code base (ext/date was planned to be used for this exact purpose > before you decided to move your code there). A separate code base is > the only way to keep user codes working. Whether user codes were good > or bad is not relevant as they worked and there was not valid > alternative in the PHP releases.
Can't this still be done? Call the new extension "datetime" or something and keep the old ext/date the way it is. A renaming process shouldn't be too problematic, right? If I had a say in this (and I don't), I'd say, keep ext/date and add another, more intelligent date/time extension. Ron

Andreas Korthaus

20 years ago
Derick Rethans wrote:
> [...], if you have any idea on how to > make things better, please step forward. I already spoke with the doc > folks how to document all the timezones that we now support.
I've learned about the limitations of the old date/time functions some time ago, so I had to implement some of the features you implemented in user space and know about some of the problems involved here. I think the new date extension/features are very valuable for PHP. But what I don't understand is, why this was implemented into old date/time functions, and not as a new extension with a new, nice OO interface like date_time (e.g.: http://cvs.php.net/co.php/pecl/date/docs/examples/sample1.php ) would have provided. So you could completely avoid all BC problems and make it much easier to work with dates/times if you choose the new extension with a new interface (see sample above). AFAIR there were plans to add an OO interface to the current date extension, but what is the advantage of having the same codebase behind the old date/time functions and a new OO interface? As we can see here, this will break a lot of existing code, because most people who will never need the new date/time features (who have written a lot of code, valid for PHP 5.x, 4.x...), are forced to use this BC breaking code - IMHO without the need. And probably this will not be very easy to fix for many people. People needing the new features (like me) would be happy if old date/time behave the same as before 5.1, and if there is a new OO interface for the new extension. Perhaps it's a good idea to restore the old date/time functions before PHP 5.1 release, and add the new functions + OO interface to the new developed date codebase, and make it a seperate extension with different interface in the documentation. Or why is the change of old functions like date() needed/useful? best regards Andreas

Lukas Smith

20 years ago
So it seems to me we have 2 issues here: 1) timing 2) code duplication or not It seems evident that the old magic never worked reliably exactly for those people that are now seemingly adversly affected by the current changes. Its just that what worked by chance may not work anymore and vice versa. Obviously for the single developer it only matters that his code would now be broken. Derick acknowledges that there is still room for improvement but its going to be impossible to get the new code to behave exactly like the old code in all cases. Now as for just keeping the old code and the new code it means code duplication which may ease the short term pains but will in the long term likely create more pains as ressources are wasted. So it seems to me like its inevitable that we at somepoint force our users to a proper portable solution as we drop the old solution. Now the question is when should we do this? Should there be an interim period where we keep both implementations? regards, Lukas

Lukas Smith

20 years ago
Andreas Korthaus wrote:
> People needing the new features (like me) would be happy if old > date/time behave the same as before 5.1, and if there is a new OO > interface for the new extension.
I dont see a pressing need for an OO API and I also dont think that PHP internal API's should one by one be moved over to an OO interface either. regards, Lukas