# IntlTimeZone::getOffset? - Thread: https://externals.io/message/68022 - Original archive: https://news-web.php.net/php.internals/68022 - Started by Stas Malyshev on 2013-06-30T21:59:40+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #68022 — Stas Malyshev — 2013-06-30T21:59:40+00:00 URL: https://externals.io/message/68022#68022 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 --- ## #68023 — Gustavo Lopes — 2013-07-01T02:13:46+00:00 URL: https://externals.io/message/68022#68023 · In reply to: #68022 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 --- ## #68024 — Stas Malyshev — 2013-07-01T02:25:26+00:00 URL: https://externals.io/message/68022#68024 · In reply to: #68023 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 --- ## #68025 — Gustavo Lopes — 2013-07-01T03:10:12+00:00 URL: https://externals.io/message/68022#68025 · In reply to: #68024 Em 2013-07-01 4:25, Stas Malyshev escreveu: > > > […] > > 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 --- ## #68026 — Stas Malyshev — 2013-07-01T03:36:30+00:00 URL: https://externals.io/message/68022#68026 · In reply to: #68025 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 --- ## #68027 — Ralf Lang — 2013-07-01T06:54:08+00:00 URL: https://externals.io/message/68022#68027 · In reply to: #68026 > Hi! > > > […] > > OK, 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