DST tests failing

[leemhenson]

Hi. When I run npm run test on master (6.16.0) locally, I get this output:

   #0 - 1 minute away from dst -

   #1 - current time 2:00am again -

   #2 - current time 2:01am -

   #3 - 2:59am is dst again -

   #4 - current time 1:01am -

   #5 - current time 1:59am -

   #6 - current time 3:00am -

   #7 - 1 minute after -

   #8 - current time 3:01am -

   #9 - 2 minutes after -

   #10 - current time 1:59am again -


           4,601 passed
  ◠◡◜◠◡-◡    11 failures

Which matches what I've just seen in my application where:

const zonedTime = spacetime("2019-11-02T00:00:00Z", "UTC").goto("Europe/London");
const startOfDay = zonedTime.startOf("day").subtract(2, "day");

console.log({
  eventTimestamp,
  zonedTime: zonedTime.toLocalDate(),
  startOfDay: startOfDay.toLocalDate(),
  intervalStart: startOfDay.goto("UTC").toLocalDate(),
  intervalEndLocal: startOfDay.add(1, "day").toLocalDate(),
  intervalEnd: startOfDay.add(1, "day").goto("UTC").toLocalDate(),
});

prints out:

    {
      eventTimestamp: 2019-11-02T00:00:00.000Z,
      zonedTime: 2019-11-02T00:00:00.000Z,
      startOfDay: 2019-10-30T23:00:00.000Z,
      intervalStart: 2019-10-30T23:00:00.000Z,
      intervalEndLocal: 1970-01-01T00:00:00.000Z,    <--- umm
      intervalEnd: 2021-04-16T09:09:51.867Z   <--- waaah?
    }

when I was expecting intervalEnd: 2019-11-01T00:00:00.000Z.

[spencermountain]

thanks Lee, yeah, my gut-sense is that this is #235 - this look like the very-close to dst tests.
That's running from Europe/London at ~10am? I've seen something like this before, but will try and reproduce it.

I'm working on a fix for 235 that will compute dst changes and store them as epochs. This will be a relief, as this bug has been trouble for a while.

• Good news, i think the 11 failing tests is actually something very minor, that will effect users at 1am, 1 day a year. when most people don't know what time it is, anyways.
  cheers!