utc.valueOf doesn't account for DST correctly

[janzipek]

Describe the bug
The utc.valueOf method doesn't correctly account for DST when $x.$localOffset is not set:

dayjs/src/plugin/utc/index.js

Lines 116 to 117 in 4a7b7d0

	const addedOffset = !this.$utils().u(this.$offset)
	? this.$offset + (this.$x.$localOffset || (new Date()).getTimezoneOffset()) : 0

the issue is it creates new Date object and retrieves the browser timezone offset from that, but if the user is in DST and the date that's being casted to timestamp is not (or vice-versa), the result is incorrect.

Minimal repro:

/*
 Expected system date settings:
 TIMEZONE: Europe/Prague (+1)
 DATE: 2022-02-11
*/

const d = dayjs('2014-06-01T12:00:00Z').tz('America/Los_Angeles')
console.log(d.format()) // correct - 2014-06-01T05:00:00-07:00
console.log(new Date(d.valueOf()).toISOString()) // incorrect 2014-06-01T11:00:00.000Z, expected 2014-06-01T12:00:00.000Z
console.log(d.valueOf()) // incorrect 1401620400000, expected 1401624000000

Expected behavior
The browser timezone offset should be calculated from the date itself, not new instance. Something like this:

  proto.valueOf = function () {
    const addedOffset = !this.$utils().u(this.$offset)
      ? this.$offset + (this.$x.$localOffset || this.$d.getTimezoneOffset()) : 0
    return this.$d.valueOf() - (addedOffset * MILLISECONDS_A_MINUTE)
  }

Information

• Day.js Version v1.10.7

[xvaara]

there is a pull request to fix this #1448 and there is a plugin in the pulls conversation to fix this while we wait.
but since it's a year old and not merged (even though it's a big problem), one has to wonder where to focus of this project is.

[iamkun]

fixed in #1448