Hi All,
I note that here in California (DateAndTime localTimeZone offset asSeconds / 60) rounded = -420 but surely in CA it is +420 ??
;-) _,,,^..^,,,_ best, Eliot
Nope, CA is 7 hours behind UTC - hence the -420. And Google backs me up on this: [image: image.png] Of course, with the current implementation of DateAndTime, where the date/time is stored in local time, the offset is...weird. You have to subtract the offset to get to UTC. If/when we adopt the UTCDateAndTime package, then the internal represenatation and offset mirrors the rest of the industry, where you add the offset to the internal UTC time to get to the local time.
-cbc
On Thu, Oct 25, 2018 at 11:11 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
I note that here in California (DateAndTime localTimeZone offset asSeconds / 60) rounded = -420but surely in CA it is +420 ??
;-) _,,,^..^,,,_ best, Eliot
I think Eliot was making a 420 / California joke...
On Thu, Oct 25, 2018 at 1:19 PM Chris Cunningham cunningham.cb@gmail.com wrote:
Nope, CA is 7 hours behind UTC - hence the -420. And Google backs me up on this: [image: image.png] Of course, with the current implementation of DateAndTime, where the date/time is stored in local time, the offset is...weird. You have to subtract the offset to get to UTC. If/when we adopt the UTCDateAndTime package, then the internal represenatation and offset mirrors the rest of the industry, where you add the offset to the internal UTC time to get to the local time.
-cbc
On Thu, Oct 25, 2018 at 11:11 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
I note that here in California (DateAndTime localTimeZone offset asSeconds / 60) rounded = -420but surely in CA it is +420 ??
;-) _,,,^..^,,,_ best, Eliot
ahhhhhh. didn't catch that. color me blushed.
On Thu, Oct 25, 2018, 11:25 Chris Muller asqueaker@gmail.com wrote:
I think Eliot was making a 420 / California joke...
On Thu, Oct 25, 2018 at 1:19 PM Chris Cunningham cunningham.cb@gmail.com wrote:
Nope, CA is 7 hours behind UTC - hence the -420. And Google backs me up on this: [image: image.png] Of course, with the current implementation of DateAndTime, where the date/time is stored in local time, the offset is...weird. You have to subtract the offset to get to UTC. If/when we adopt the UTCDateAndTime package, then the internal represenatation and offset mirrors the rest of the industry, where you add the offset to the internal UTC time to get to the local time.
-cbc
On Thu, Oct 25, 2018 at 11:11 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
I note that here in California (DateAndTime localTimeZone offset asSeconds / 60) rounded = -420but surely in CA it is +420 ??
;-) _,,,^..^,,,_ best, Eliot
On Thu, 25 Oct 2018 at 20:11, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
I note that here in California (DateAndTime localTimeZone offset asSeconds / 60) rounded = -420but surely in CA it is +420 ??
Nope, +420 is the Czech Republic (https://countrycode.org/czechrepublic)
:-)
squeak-dev@lists.squeakfoundation.org
-
Alistair Grant -
Chris Cunningham -
Chris Muller -
Eliot Miranda