Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68025
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 01 Jul 2013 05:10:12 +0200
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP Internals <internals@lists.php.net>
Organization: =?UTF-8?Q?N=C3=BAcleo_de_Engenharia_Biom=C3=A9dica_do_Insti?=
 =?UTF-8?Q?tuto_Superior_T=C3=A9cnico?=
In-Reply-To: <51D0E896.10300@sugarcrm.com>
References: <51D0AA4C.9020805@sugarcrm.com>
 <2e3d0947cdbe7832ec27295eadad9b5d@nebm.ist.utl.pt>
 <51D0E896.10300@sugarcrm.com>
Message-ID: <d9af685a6e261684b4bbcedd458a4e58@nebm.ist.utl.pt>
User-Agent: RoundCube Webmail/0.8-rc
Subject: Re: =?UTF-8?Q?IntlTimeZone=3A=3AgetOffset=3F?=
From: glopes@nebm.ist.utl.pt (Gustavo Lopes)

Em 2013-07-01 4:25, Stas Malyshev escreveu:
>
>> It can be a UTC timestamp (if $local is false), but note it's in
>> milliseconds since the epoch, not seconds. The documentation is 
>> here:
>
> It looks like it's the only place in PHP where we represent date this
> way. Given that this function has no docs at all, it's even more
> confusing.

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

> Can't we make it work in line with all other PHP functions
> that deal with dates? I understand ICU does it this way, but should 
> we
> really make the API mimic ICU so closely? How would one use such 
> function?

The other functions outside ICU don't work with anything smaller than 
the second, so they're not directly comparable. It is true, however, 
that IntlDateFormatter and MessageFormatter work with (possibly 
fractional) seconds.

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 
changing the API to take fractional seconds is a good idea, but I should 
point out that there are policy reasons that would advise against such a 
change -- namely, it's in a stable release. At this point, the reliance 
interest is small because 5.5.0 (and intl v3) has been out for little 
time, but perhaps, if anything is to be done, other options such as 
introducing an object type just for encapsulating timestamps would be 
preferable.

-- 
Gustavo Lopes