date filter appears to add DST correction to UTC dates

[DeeUnderscore]

Consider this example:

const { Liquid } = require("liquidjs");
const engine = new Liquid({
  timezoneOffset: "Etc/GMT",
});

engine.parseAndRender(
`{{ "2023-04-05T12:00:00Z" | date: "%Y-%m-%dT%H:%M:%S%z", "Etc/GMT" }}
{{ "2023-01-05T12:00:00Z" | date: "%Y-%m-%dT%H:%M:%S%z", 0 }}
{{ "2023-01-05T12:00:00Z" | date: "%Y-%m-%dT%H:%M:%S%z", "Etc/GMT" }}
{{ "2023-01-05T12:00:00Z" | date: "%Y-%m-%dT%H:%M:%S%z" }}
{{ "2023-01-05T12:00:00+0000" | date: "%Y-%m-%dT%H:%M:%S%z", 0 }}`
).then(console.log);

The output this produces:

2023-04-05T12:00:00+0000
2023-01-05T11:00:00+0000
2023-01-05T11:00:00+0000
2023-01-05T11:00:00+0000
2023-01-05T11:00:00+0000

I am in a timezone which does not use DST in January, but uses it in April. UTC never uses DST, but the January dates appear corrected for UTC (and still report +0000 offset).

This also happens with preserveTimezones set to true, and it happens with dates passed in as data:

const inputDate = new Date("2023-01-05T12:00:00Z");
console.log(`toISOString(): ${inputDate.toISOString()}`);

engine.parseAndRender(
'Liquid: {{ inputDate | date: "%Y-%m-%dT%H:%M:%S%z", "Etc/GMT" }}', { inputDate: inputDate }
).then(console.log)
// Output:
// toISOString(): 2023-01-05T12:00:00.000Z
// Liquid: 2023-01-05T11:00:00+0000

This is with liquidjs 10.7.0

[harttle]

Sorry I'm not familar with DST, it seems to correct all dates (even January) when you're now in DST. I'll dig into this issue latter.

Another case for GMT/UTC like 2023-01-05T12:00:00+0000 it's surely a bug. We should never adjust it when both input & output are in UTC.

[DeeUnderscore]

2023-01-05T12:00:00Z should be UTC too, since the Z timezone specifier means UTC. All of these should round-trip back to the same datetime.

What seems to be happening is that the local DST is applied to date calculations for all timezones, and seems to depend on whether or not current time at execution is on the same side of DST as the date being rendered.

In 2023, America/New_York started DST on March 12th, while Europe/Paris started DST on March 26th, which means that on March 20th, DST was active in New York, but not active in Paris. We can come up with this test case, where New York is on the same side of DST as right now, and Paris is not:

const inputDate = new Date("2023-03-20T12:00:00Z");
console.log(inputDate.toLocaleString("en-US", { timeZone: "America/New_York" }));

engine.parseAndRender(
`America/New_York: {{ inputDate | date: "%Y-%m-%dT%H:%M:%S%z", "America/New_York" }}
Europe/Paris: {{ inputDate | date: "%Y-%m-%dT%H:%M:%S%z", "Europe/Paris" }}`, { inputDate: inputDate }
).then(console.log)

which gives the following results:

$ TZ=America/New_York node test.js
3/20/2023, 8:00:00 AM
America/New_York: 2023-03-20T08:00:00-0400
Europe/Paris: 2023-03-20T13:00:00+0100
$ TZ=Europe/Paris node test.js
3/20/2023, 8:00:00 AM
America/New_York: 2023-03-20T07:00:00-0400
Europe/Paris: 2023-03-20T12:00:00+0100

The New York time output by liquidjs should stay the same regardless of local timezone (and equal to what toLocaleString outputs).

[github-actions]

🎉 This issue has been resolved in version 10.7.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[harttle]

Thanks @DeeUnderscore , your test cases helped a lot. Try v10.7.1, please let me know if any issue persists.

[DeeUnderscore]

Looks like it's solved in 10.7.1 for me. Thank you!