Re: timezones & date() breakage

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 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.

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.