fix: tz with DST date while DST is not active (#1340)

[hansdaniels]

@addisonElliott, your last suggestion made my new tests work and also no longer break the existing tests.
No complains about keepLocalTime.

[addisonElliott]

Glad to hear it. This should resolve most DST issues people have experienced.

I would recommend adding tests for the bug that this fixes. Using that specific date you had in the issue should work for a good test.

[codecov]

Codecov Report

Merging #1352 (0170f24) into dev (e93e6b8) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##               dev     #1352   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          176       176           
  Lines         1737      1737           
  Branches       394       394           
=========================================
  Hits          1737      1737           

Impacted Files	Coverage Δ
src/plugin/timezone/index.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e93e6b8...0170f24. Read the comment docs.

[hansdaniels]

I've added 2 expects to an already existing test case for DST in test/plugin/timezone.test.js. One date with DST, one without, exactly what I needed. Before I have applied your suggested changes, the DST expect failed, afterwards both passed.

The exact date minutes before and after a DST change for 'Europe/Berlin' aren't any more special than dates in December and June for 'America/Los_Angeles' as used in the "DST" testcase.

[hansdaniels]

Side-Problems:

• Commiting from Windows is hard, eslint complains when having files checked out with CRLF (even if I have told Git to commit with LF).
• The pre-commit hook failed because eslint wasn't a known command. I've circumvented this by running node node_modules/eslint/bin/eslint.js src/* test/* build/* manually and commiting with -n which shouldn't be necessary to my eyes.

[alex-w0]

Is this pull request related to this issue?

[addisonElliott]

@alex-w0 I think so, but I'm not entirely sure. This bug fixes UTC offsets for DST-related timezones (pretty vague I know). Best way is going to be trying the failing tests from the issue after applying this change.

[iamkun]

nice catch

[addisonElliott]

@iamkun Do you need anything in order to merge this?

[ashconnell]

I think this commit has just made things worse.

Edit: plot twist, it didn't. My brain is just fried from looking at dates all day. Kindly ignore me.

I'm specifically seeing this issue: #1437

So I checked this commit out on dev and added a test for my real world scenario:

it('DST startOf(day)', () => {
  const beforeDST = dayjs
    .tz('2021-04-01 08:00', 'Australia/Melbourne')
    .startOf('day')
    .format()
  expect(beforeDST).toBe('2021-04-01T00:00:00+11:00')
  const afterDST = dayjs
    .tz('2021-04-15 08:00', 'Australia/Melbourne')
    .startOf('day')
    .format()
  expect(afterDST).toBe('2021-04-15T00:00:00+11:00')
})

And the output of the second expect comes out like this:

2021-04-15T00:00:00+10:00

Note that the offset is +10:00 and not +11:00

[iamkun]

🎉 This PR is included in version 1.10.5 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[henhal]

This commit seems to be the reason for quite a few problems, including #1795 , which seems to be similar to what @ashconnell reported almost a year ago. This is really critical.

[kevinsimper]

I think this also gives problems
Here you can see a dayjs object

    M {
      '$L': 'en',
      '$offset': 60,
      '$d': 2021-01-04T08:00:00.000Z,
      '$x': { '$timezone': 'Europe/Stockholm' },
      '$y': 2021,
      '$M': 0,
      '$D': 4,
      '$W': 1,
      '$H': 9,
      '$m': 0,
      '$s': 0,
      '$ms': 0
    } 

and then running toISOString() gives this output now

2021-01-04T09:00:00.000Z

I upgraded from 1.10.4 to 1.11.0

This is the result in 1.10.4

      d {
        '$L': 'en',
        '$offset': 120,
        '$d': 2021-01-04T08:00:00.000Z,
        '$x': { '$timezone': 'Europe/Stockholm' },
        '$y': 2021,
        '$M': 0,
        '$D': 4,
        '$W': 1,
        '$H': 9,
        '$m': 0,
        '$s': 0,
        '$ms': 0
      } 
2021-01-04T08:00:00.000Z