Unexpected epoch return value without dst

[rmunoz]

Hi, I'm playing with your package and I think that I found a problem with the returned epoch value. Here is the code:

var spacetime = require('spacetime');

var s1 = spacetime([2017, 9, 4, 10, 20, 0, 0], 'Europe/Madrid');
console.log("[spacetime] iso date: " + s1.format('iso') + "  epoch: " + s1.epoch);
console.log("[spacetime] tz name: " + s1.timezone().name);
console.log("[spacetime] offset: " + s1.timezone().current.offset);
console.log("[spacetime] isDst: " + s1.timezone().current.isDst);

// There is a DST change on 29-10-2017 at 03:00:00

var s2 = spacetime([2017, 9, 30, 10, 20, 0, 0], 'Europe/Madrid');
console.log("[spacetime] iso date: " + s2.format('iso') + "  epoch: " + s2.epoch);
console.log("[spacetime] tz name: " + s2.timezone().name);
console.log("[spacetime] offset: " + s2.timezone().current.offset);
console.log("[spacetime] isDst: " + s2.timezone().current.isDst);

And the output is:

[spacetime] iso date: 2017-10-04T10:20:00:000Z  epoch: 1507105200000
[spacetime] tz name: Europe/Madrid
[spacetime] offset: 120
[spacetime] isDst: true
[spacetime] iso date: 2017-10-30T10:20:00:000Z  epoch: 1509358800000
[spacetime] tz name: Europe/Madrid
[spacetime] offset: 60
[spacetime] isDst: false

If I use https://www.epochconverter.com/ with the first epoch (1507105200000) I see what I expect, the GMT value is: "GMT: Wednesday, October 4, 2017 8:20:00 AM" because there is a 120 offset.

But If I set the second epoch (1509358800000) the GMT value is unexpected: "GMT: Monday, October 30, 2017 10:20:00 AM". What I expect should be GMT: Monday, October 30, 2017 09:20:00 AM because there is a 60 offset.

There is a bug or I'm missing something?
Thanks

[spencermountain]

hi Ricardo, thanks for the bug, it's nice to see people kicking the tires. It's a pretty-new library. What do you think so far?

yeah, there may just be a confusion with the api - try this?

var s = spacetime(1509358800000, 'Europe/Madrid');
s.log()
//Oct 30th, 11:20am

[spencermountain]

yeah, nm. i just reproduced this. You're right about this. something is fishy.
i added some failing tests to capture it.

[spencermountain]

agh, got this in v2.1.1. this was really hard!
https://runkit.com/spencermountain/5a0f528478a603001292d3c1
relevant tests
thanks.