Fractional Timezone Support

[stabback]

It looks like Spacetime has a bit of trouble with fractional timezones, and gets a bit confused with reading in timezones that are ahead / behind GMT. Example:

// Create a starting place (noon today GMT)
s = spacetime('2018-08-28T12:00:00Z')

// Setup some timezones to look at
let timezones = [
  {
    timezone: 'America/Toronto',  // -4h
  },
  {
    timezone: 'Asia/Muscat', // +4h
  },
  {
    timezone: 'Asia/Kathmandu', // +5h 45m
  },
  {
    timezone: 'Asia/Calcutta', // +5h 30m
  }
]

timezones = timezones.map(tz => {
  // Create a version of the above time in this timezone
  thisSpacetime = s.clone().goto(tz.timezone)
  offset = thisSpacetime.timezone().current.offset,
  nice =  thisSpacetime.format('nice')
  iso = thisSpacetime.format('iso')
  
  // Create a (hopefully identical) version of the above timezone
  interpreted = spacetime(iso)
  interpretedOffset = interpreted.epoch ? interpreted.timezone().current.offset : '',
  interpretedIso = interpreted.format('iso')
  interpretedNice = interpreted.format('nice')

  return {
    ...tz,
    offset,
    nice,
    iso,
    interpretedOffset,
    interpretedIso,
    interpretedNice
  }
})

console.table(timezones)

Outputs the following:

Issues:

1. The generated ISO timestamps appear to have the timezone backwards - for Toronto, I would expect a timestamp of "2018-08-28T08:00:00.758-04:00", not "2018-08-28T08:00:00.758+04:00"
2. ST seems to interpret all positive number timezones as negative numbers (see the interpretted timezone of Asia / Muscat differing from the original offset)
3. The generated ISO dates for Asia/Kathmandu and Asia/Calcutta is not a proper ISO timestamp, and as such can't be accepted as input to spacetime

I'm willing to chalk some of this up to my inexperience with the lib / confusion with timezones.

[spencermountain]

hey Josh, no thank you, this is a great bug
looks like i'm sloppily writing 1.5 into the iso timestamp.

let s=spacetime.now().goto('Asia/Calcutta')
console.log( s.format('iso'))
//2018-08-29T19:46:37.251-5.5:30

will fix it this week!
cheers

[stabback]

Great, thanks for the quick reply!

Are points number 1 & 2 above also valid?

[spencermountain]

oh yeah, I think they're the same thing. It would be good to have a second pair of eyes on this. It seems weird, but it was intentional, if I remember, to reverse the offset in the ISO format.
I agree it makes no sense. Can you check how moment, or date-fns do it?

[tuqire]

@spencermountain I can clarify moment at least works as @stabback suggests.

[spencermountain]

ah, yeah. you two are right. Here's moment/luxor
https://runkit.com/spencermountain/5b8acdaaed7d5b0012a94407

damn, how did I get this backwards.
fixed the fractional offset iso string issue, but this will be a major :/

gonna give it half an hour. let's see.

[spencermountain]

bah - here it is - https://askubuntu.com/questions/519550/why-is-the-8-timezone-called-gmt-8-in-the-filesystem

yeah, we're mapping iso ...-05:00 to Etc/GMT-5, which has an offset of +5..
gonna start mapping iso -05 to Etc/GMT+5 and that should do the trick, and fail all the tests...

[spencermountain]

okay, it's out 4.4.0, can you guys check it?
will leave this open until someone else's brain looks at the output

[tuqire]

@spencermountain I will take a look over the coming day or so. Thanks for the quickfix!

[stabback]

@spencermountain Sorry for going dark on this, just got back from a vacation. Thanks for resolving!