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