In regards to the BIF `getTimeZoneInfo()`, am I th...
# cfml-general
b
In regards to the BIF
getTimeZoneInfo()
, am I thinking wrong, or is this part of the return value backwards?
• `utcTotalOffset`: offset of local time, in seconds, from UTC
◦ A plus sign indicates a time zone west of UTC (such as a zone in North America)
◦ A minus sign indicates a time zone east of UTC (such as a zone in Germany)
The US, for example, would be before UTC and have a time less than UTC, so central should have an off negative 6 hours, not positive 6 hours, right?
It's worth noting, Lucee has an additional key in the returned struct called
offset
which appears to have the "correct" positive/negative offset.
s
guess if you look at it relative to the local it makes sense? wonder if that's what they there thinking
a
It's def not how I'd implement it, no. The way the offset seems to be implemented is "what do you need to add to get to UTC", which is not really how we humans think, is it? One doesn't go "I need to add 5h to my time in EST to get to UTC", we think "EST is offset from UTC by -5h". When considering TZs, UTC is always the baseline. It's not "my current TZ is the baseline, and how far is UTC offset from this?"
Is it an overlay of something in Java, and there's a better explanation of what's going on in the Java docs?
(I say all this as being someone who is resident in the UTC TZ, so perhaps I'm biased...)
r
I tend to think of it as “my timezone is 7 hours behind UTC” so the offset for my timezone is -7 hours. If it is 23:00 in Adam’s pub, it is 16:00 in mine. He’s finishing up, I’m getting started.
a
He’s finishing up
Don't be so sure of that...
r
OK, fair. 🙂
a
(in all honesty, these days it's 50/50 if I make it to closing time)
b
@rstewart Agreed, that's how I think of it too. In my mind, the offset is what I should add to UTC to reach my time zone.
Which is why it's normally written something like this. (notice the negative):
Copy code
UTC−06:00
e.g. CST is "offset - 6 hours" because you have to subtract 6 hours from UTC to get the CST time.
2
Related tickets to address some annoying differences between the engines. https://luceeserver.atlassian.net/browse/LDEV-3902 https://tracker.adobe.com/#/view/CF-4212849
z
Lucee now has a timezone key for compat
❤️ 1
s
@zackster Do you mean this:
It's worth noting, Lucee has an additional key in the returned struct called offset which appears to have the "correct" positive/negative offset.
(which is what Brad said at the beginning of this thread)
z
just added
timezone
which is the same as the existing
id
key for compat https://github.com/lucee/Lucee/commit/c93dcfe71dc3cb3a542b75d0bc40f82a0843102c
I already added the a heap of extra stuff a few years ago, let me know if anything else is needed https://trycf.com/gist/379999e3443de6f1aa77a6ec88b1fdda/lucee5?theme=monokai
b
@seancorfield No, he was referring to the Lucee ticket I posted above. Upon noticing Adobe and Lucee have their own unique keys in the struct they return, I entered tickets for both of them to add the features unique to the other engine. So I did put in a ticket to add the "offset" key, but that was in the ticket I gave Adobe.
👍🏻 1
s
Timezones are hard 🙂
2