Spacetime appears to ignore timezone when parsing ISO times about spacetime HOT 11 CLOSED

I believe the ISO date format (with timezone) is an absolute timestamp, not a relative one—i.e. the offset is always the offset from GMT, not relative to your current timezone.

If that's true, then I believe the two ways of specifying the timezone should be mutually exclusive, and I believe the ISO offset should take precedence.

If both are given, I see no issue with ignoring the second argument (you could also log a warning).

This would also be very easy to understand for users of this library (as opposed to the complex maths of relative offsets), and it makes it compatible with anyone who is working with dates from a standard API (like I am) which include timezone in the timestamp.

I don't know the library well enough to suggest how this should be suggested, but if you agree I might be able to take a look at putting a PR in... 👍

from spacetime.

@spencermountain yeah that works! as long as the warning can be disabled in config... 😉

from spacetime.

Can see this has been released—thanks! Should this be closed?

from spacetime.

hey Sam, yeah i think I see what you mean.
if i can remember, i started parsing the timestamp, ran into the timezone, and thought, hmm should this over-ride a timezone entered as the second param? Then i thought, how should we guess which timezone it is, given the offset? then i thought, man, it's almost lunch time.

so yeah, my bad ;)

if you pass a iana timezone in the second param, you should get your expected behaviour I believe.
would be happy to merge any solution to handling this. up to you!
cheers

from spacetime.

hey, maybe this?:
we add UTC-7, and so forth, to the zonefile, which have no dst changes.
if we get a -0700 suffix on the timestamp, we overwrite (any?) given timezone as second param, ... unless it's ...currently the same offset?

worse is the condition when you say spacetime('xxx--0700', 'Europe/London') - because then it's a double-conversion. I suppose we could try to support that - ie find x-oclock in 7-offset, then find out what time that is in london.
yikes!
(just thinking aloud)

from spacetime.

Couple points of clarification: ISO 8601 defines a broad standard for representation of dates, not a singular form for dates.

Additionally, I believe offsets are relative to UTC, not GMT. In the real world they are basically the same, but represent different things. One example: iirc the actual GMT timezone isn't used while the UK goes on British Summer Time.

from spacetime.

Of course, my bad about GMT ≠ UTC, I get lazy being in the UK...

Regardless of the broad standard, I still believe the absolute offset is the easiest way to work with timezones if you'd like to accept the format which includes a timezone offset in the timestamp? Although open to any ideas you'd prefer 😊

from spacetime.

hey, got this working and I'm somewhat happy with it - atleast it didn't destroy any passing-tests.

this look alright?
will be in v3.0

from spacetime.

@spencermountain LGTM! Out of curiosity, are you going with ignoring the second argument if the first has a timezone included? Or has the API changed in 3.0?

Thanks for this, going to be really helpful!

from spacetime.

hey yeah, it would ignore the 2nd argument if it's there.
I thought about adding a warning message if that's the case. Maybe I should do that today.

from spacetime.

yeah, new console.warn behaviour in the next release:

const s = spacetime('2017-04-03T08:00:00-0700', 'Canada/Eastern')
/*  - Setting timezone to: 'Etc/GMT-7'
     from ISO string '-0700'
     overwriting given timezone: 'Canada/Eastern'*/

what do you think Sam?

from spacetime.