hour difference for different years in wasm32

[sergeyt]

I'm trying to use chrono strftime in wasm.
I'm getting strange hour difference when trying to format timestamp passed from JavaScript.

I've created this repo to reproduce the issue.

I have the following function:

extern crate chrono;

use wasm_bindgen::prelude::*;
use chrono::prelude::*;

#[wasm_bindgen]
pub fn format_strftime(format: &str, timestamp: f64) -> String {
    let off = Local::now().offset().fix();
    let d = off.timestamp_millis(timestamp as i64);
    return d.format(format).to_string();
}

and this test is failing

/**
 * @jest-environment node
 */
const wasm = require("../pkg/index.js");

describe("chrono", () => {
  it("hour diff", () => {
    let diffs: any = {};
    for (let y = 0; y <= 2020; y++) {
      const d = new Date();
      d.setFullYear(y);
      d.setHours(13);
      const expected = String(d.getHours());
      const actual = wasm.format_strftime("%H", d.getTime());
      if (actual !== expected) {
        const key = String(parseInt(expected, 10) - parseInt(actual, 10));
        const dif = diffs[key] || (diffs[key] = { ranges: [] });
        const range = dif.ranges.find((r) => y >= r[0] && y <= r[1] + 1);
        if (range) {
          range[1] = y;
        } else {
          dif.ranges.push([y, y]);
        }
      }
    }
    console.log(JSON.stringify(diffs, null, "  "));
    expect(Object.keys(diffs).length).toBe(0);
  });
});

I expect no difference, but this test prints the following difference:

{
      "1": {
        "ranges": [
          [
            1981,
            1990
          ],
          [
            1992,
            1993
          ]
        ]
      },
      "-1": {
        "ranges": [
          [
            0,
            1930
          ],
          [
            2015,
            2016
          ]
        ]
      }
    }

Steps to reproduce:

• nodejs v12, rustc 1.42.0
• git clone https://github.com/sergeyt/chrono-strftime-test.git
• yarn install
• yarn spec

I am running the test in nodejs environment.

I guess issue #391 is related to this somehow.

[pitdicker]

I can't easily run the included test here, but #1131 fixes what I believe is this issue.