Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19216 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 88656 invoked by uid 1010); 27 Sep 2005 19:08:45 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 88640 invoked from network); 27 Sep 2005 19:08:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Sep 2005 19:08:45 -0000 X-Host-Fingerprint: 194.73.73.209 c2bthomr01.btconnect.com FreeBSD 4.7-5.2 (or MacOS X 10.2-10.3) (2) Received: from ([194.73.73.209:11838] helo=c2bthomr01.btconnect.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id C7/9D-54476-CB899334 for ; Tue, 27 Sep 2005 15:08:44 -0400 Received: from [10.0.0.9] (host81-138-11-136.in-addr.btopenworld.com [81.138.11.136]) by c2bthomr01.btconnect.com (MOS 3.5.9-GR) with ESMTP id CZG84291; Tue, 27 Sep 2005 20:07:58 +0100 (BST) Message-ID: <433998B1.60106@lsces.co.uk> Date: Tue, 27 Sep 2005 20:08:33 +0100 Organization: L.S.Caine Electronic Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Derick Rethans CC: internals@lists.php.net References: <43393A43.4070805@lsces.co.uk> <43397E48.7080107@lsces.co.uk> <4339917B.7030304@lsces.co.uk> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] timezones & date() breakage From: lester@lsces.co.uk (Lester Caine) Derick Rethans wrote: >>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. I've got some things to check against ;) Not sure I spotted your source of data? >>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. Need to know how to adjust the calendar display around the daylight saving change! The 25 hour day and the 23 Hour day - it would be nice to highlight them for the view you are creating, especially when you are planning round the working hours restrictions ;) > 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). Originally it was, but while unix epochs look the best solution, having real timestamps that can be filtered/grouped/counted on dates without having to process every integer in the database - depending on which database engine you are using .... THAT particular 'crap performance' has still to be addressed :( -- Lester Caine ----------------------------- L.S.Caine Electronic Services Treasurer - Firebird Foundation Inc.