Re: timezones & date() breakage

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