Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56921 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23440 invoked from network); 14 Dec 2011 18:24:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Dec 2011 18:24:19 -0000 Authentication-Results: pb1.pair.com smtp.mail=chortos@inbox.lv; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=chortos@inbox.lv; sender-id=pass Received-SPF: pass (pb1.pair.com: domain inbox.lv designates 89.111.3.82 as permitted sender) X-PHP-List-Original-Sender: chortos@inbox.lv X-Host-Fingerprint: 89.111.3.82 shark2.inbox.lv Received: from [89.111.3.82] ([89.111.3.82:35594] helo=shark2.inbox.lv) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FC/83-02473-1D9E8EE4 for ; Wed, 14 Dec 2011 13:24:18 -0500 Received: from mail.inbox.lv (pop [10.0.1.110]) by shark2-plain.inbox.lv (Postfix) with ESMTP id B8CDCA277; Wed, 14 Dec 2011 20:24:14 +0200 (EET) Received: from [192.168.1.139] (unknown [77.38.233.95]) (Authenticated sender: chortos@inbox.lv) by mail.inbox.lv (Postfix) with ESMTPSA id 9698F622E5; Wed, 14 Dec 2011 20:24:14 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii In-Reply-To: Date: Wed, 14 Dec 2011 20:24:14 +0200 Cc: PHP Developers Mailing List Content-Transfer-Encoding: quoted-printable Message-ID: References: <8D58A664-7250-4FEE-9424-2D2DEFC69308@inbox.lv> <1C397FE3-76E2-473B-B47F-194DAF3ACB39@inbox.lv> To: Derick Rethans X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: OK Subject: Re: [PHP-DEV] Local time zone From: chortos@inbox.lv (Oleg Oshmyan) > I suggest you lobby distributions that bundle PHP to add a = post-install=20 > script for "dpkg-reconfigure tzdata" to drop a datetime.ini file in=20 > /etc/php5/conf.d with as contents "date.timezone=3D timezone>". This is a good idea (or perhaps exactly the opposite, as I explained in = my previous email, but still needed if PHP drops all and any support for = system-provided local time), but sometimes people use local copies of = PHP instead of system-wide ones or their systems do not come with PHP at = all. > Using the information from /etc/localtime is *not* enough as=20 > you can't get the timezone identifier out of it. The time zone identifier would be System. No need to extract one from = /etc/localtime. > That will never happen. The whole idea with the new support is to get=20= > *away* from OS idiosyncrasies and not adding more of them! PHP needs = to=20 > be able to rely on its own bundled timezone database. Parsing files on=20= > the filesystem is slow and silly. Why is it bad to have this as added functionality? Why are you worried = about PHP's ability to rely on its own bundled time zone database? Let = me explain my idea once again: I propose **leaving all existing functionality alone** and **adding a = new time zone** called System. * All existing time zones will work as they do in PHP 5.4 RC3. The = internal time zone database will be used, the internal timezone-aware = code will be used and the system will not be consulted at all. Any PHP = code using existing time zones will remain perfectly portable across all = PHP installations. * date_default_timezone_get will work as it does in PHP 5.4 RC3. Perhaps = there is confusion because I initially proposed restoring the guessing = algorithm, so let me make this clear: this is a separate suggestion. So, = once again: date_default_timezone_get will work as it does in PHP 5.4 = RC3. * There will be a new time zone called System. When this time zone is = active, instead of PHP's internal time zone database and timezone-aware = code, system-provided local time APIs are used. In previous emails, I = said things like 'system-provided local time description and/or APIs' = but they seem only to increase confusion, so let me drop that part. This = System time zone will obviously have some system-dependent behaviour, = share the system's idiosyncrasies etc. but this is *the whole point*: if = the programmer wants them, they should be able to get them. We have two extremes: portability across systems and blending in with = the current system; just like there are two extremes in GUI design: the = same GUI being used on all platforms is good because users of the = software can freely switch between platforms, but having the common look = and feel of the platform the software is running on is good because = users of the platform feel at home. PHP's time zone functionality = currently forces the programmer to be at the portability extreme; my = suggestion is to let the programmer choose which extreme to be at. (The reasoning for 'system-provided local time description and/or APIs' = was that it might be easier to implement some functions by converting = /etc/localtime to PHP's internal representation and using PHP's existing = internal timezone-aware code than by making a new code branch that calls = into the system. As for restoring the guessing algorithm, I suggested = that merely as an easier alternative to making a whole new time zone = that consistently uses system-provided APIs.) --=20 Oleg=