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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
