Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68026 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77706 invoked from network); 1 Jul 2013 03:36:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Jul 2013 03:36:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.91 smtp91.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.91] ([108.166.43.91:45633] helo=smtp91.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F6/32-63159-249F0D15 for ; Sun, 30 Jun 2013 23:36:34 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 78B8A1400A8; Sun, 30 Jun 2013 23:36:31 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 21AEF1400A2; Sun, 30 Jun 2013 23:36:31 -0400 (EDT) Message-ID: <51D0F93E.4080505@sugarcrm.com> Date: Sun, 30 Jun 2013 20:36:30 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Gustavo Lopes CC: PHP Internals References: <51D0AA4C.9020805@sugarcrm.com> <2e3d0947cdbe7832ec27295eadad9b5d@nebm.ist.utl.pt> <51D0E896.10300@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: IntlTimeZone::getOffset? From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > This is not correct. Some functions in IntlCalendar also use this > direct representation of UDate, see e.g. > > http://pt2.php.net/manual/en/intlcalendar.getnow.php > http://pt2.php.net/manual/en/intlcalendar.gettime.php OK, I see. > As far as I know, there's not any strictly technical reason to prefer > working milliseconds rather than seconds short of saving some arithmetic > operations before passing the values to ICU -- I don't think the > rounding error introduced by dividing by 1000 is relevant for the sort > of dates one is likely to work with. I take no position on whether I am just surprised we have an API that works differently from all other APIs in PHP, and for what seems to be not better reason that compatibility with internal representation of the library (which we don't preserve in many other cases). Re-reading the mail thread back when it was merged, I recall now I was surprised by that back then too. Could we at least have some documentation for it so that it could be clear what's going on and how these functions go together? Since we had no RFC for this functionality at all, and still no docs except for skeletal ones more than a year after merge, it makes it really hard to understand what's going on. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227