Stanislav, You are absolutely right. date() has always worked just fine and 100% reliable. Maybe it wasn't suitable for certain applications, but for others it has been very suitable. If it is decided that the date extension will be replaced by new behavior and will break older applications, I think you are making a hell of a mistake. BC is easy in this case, and should be a big priority. Apparently, for some people, it is not. I don't see the problem of having 2 date extensions. If people don't want to use the older date extension, they can just compile PHP without it, right? I don't see the big deal in providing solid BC, which should be very easy.
Almost every application I wrote uses date() and a lot of them do not rely on timezones at all. Why should 5.1 break my applications if it doesn't have to? My applications work 100% fine and reliable with the 5.0 date extension. Let's keep it that way, shall we? No offence, but should pride, stubbornness and shortsightedness force many thousands of people into reviewing all their applications? Ron "Stanislav Malyshev" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > LS>>You honestly claim that the current code makes it possible to write portable > LS>>code? Anyone who has ever tried to write a calendar app in PHP will tell you > LS>>that timezone handling is beyond subpar in PHP. > > I wrote "did exactly what I wanted it to do - show current time on the > machine". Yes, it was honestly portable - on each machine that PHP ran it > showed the exact time that was on system's clock. It can be it was not fit > for multiuser multitimezone calendar app - so what? Did I ever say you > must use date() for it? Or that you can't improve date() to work with it? > Sure you can. Just don't break the working parts. You seem to concentrate > on only application you need and ignore the fact that there are other > applications that have different needs. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
