possible bug in DateAndTime localTimeOffset

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:

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 <[hidden email]> wrote:

Hi All,

    I note that here in California

        (DateAndTime localTimeZone offset asSeconds / 60) rounded = -420

but 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 <[hidden email]> wrote:

Nope, CA is 7 hours behind UTC - hence the -420.

And Google backs me up on this:

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 <[hidden email]> wrote:

Hi All,

    I note that here in California

        (DateAndTime localTimeZone offset asSeconds / 60) rounded = -420

but surely in CA it is +420 ??

;-)

_,,,^..^,,,_

best, Eliot