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