Hi!
I have a question about IntlTimeZone::getOffset - what is the first
parameter it accepts? Is it UTC timestamp? The type is double, but I'm
not sure what exactly this double is supposed to mean.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Em 2013-06-30 23:59, Stas Malyshev escreveu:
I have a question about IntlTimeZone::getOffset - what is the first
parameter it accepts? Is it UTC timestamp? The type is double, but
I'm
not sure what exactly this double is supposed to mean.
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:
http://www.icu-project.org/apiref/icu4c/classicu_1_1TimeZone.html#a026e66c6f698915089c3a3ab29dfd80b
And for UDate (which is typedefed to double in ICU4C and represented as
a float in PHP):
http://www.icu-project.org/apiref/icu4c/utypes_8h.html#ace1704e9e77d407d1eaaa2e73ec0c039
If $local is false, then it's a "local" timestamp; from what I can
tell, this is the UTC timestamp of the relevant instant + effective
timezone offset at that instant. Put another way, the local timestamp is
the UTC timestamp that would yield the same UTC date/time as the local
wall time at issue. This has the usual problems at DST transitions, see
this comment:
http://lxr.php.net/xref/THIRD_PARTY/ICU4C/source/i18n/timezone.cpp#661
--
Gustavo Lopes
Hi!
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. 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?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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
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
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.phpOK, I see.
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.
Converting between php based timestamps (s based) and javascript
timestamps (s/1000 based) is confusing enough. If PHP introduces s/1000
based timestamps, I think it's best to have a consistent set of
functions/classes that all accept the same.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537