fix: offset calculation of timezone plugin

[Pareder]

Update calculation of timezone offset. This change was caused by this issue #2207. The thing is that Hermes in React Native doesn't fully support Intl API (facebook/hermes#23). Let me explain.

This code:

const target = date.toLocaleString('en-US', { timeZone: timezone })

works correct, it returns the date in en-US format, but after that when returned string is passed to Date constructor it returns Date { NaN }:

const target = date.toLocaleString('en-US', { timeZone: timezone })
new Date(target) // Date { NaN }

Date constructor cannot recognise this format, so calculation of difference is broken. And I think that we can use dayjs to do backward formatting.

Note: in my opinion we can improve somehow the calculation of timezone offset not to depend on some APIs support (get rid of Date.toLocaleString).

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (2254635) 100.00% compared to head (4567b8d) 100.00%.

❗ Current head 4567b8d differs from pull request most recent head 5c7598a. Consider uploading reports for the commit 5c7598a to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##               dev     #2227    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files          183       183            
  Lines         2249      2112   -137     
  Branches       636       555    -81     
==========================================
- Hits          2249      2112   -137     

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

... and 5 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[iamkun]

not sure if this is a correct fix, is there a way to add some test cases to prove it right?

[Pareder]

@iamkun None of timezone tests is broken, what test do you want me to add? Do you want to simulate Date { NaN } behavior or what?

[iamkun]

can we use d(target) directlly?

[Pareder]

Actually we can't use it, because parseDate method returns new Date (https://github.com/iamkun/dayjs/blob/dev/src/index.js#L79), which is the reason of this PR and in case of using customParseFormat plugin without passing format argument it calls original parseDate method under the hood https://github.com/iamkun/dayjs/blob/dev/src/plugin/customParseFormat/index.js#L257. So my fix will work only when using customParseFormat plugin, what do you think about it?

[iamkun]

True, that's my concern. If we implement it in this way, the timezone plugin must rely on customParseFormat plugin to work that our users may get confused

[Pareder]

I got your point. Maybe I can find a better solution to calculate timezone offset not to depend on some APIs support.

[Pareder]

@iamkun Could you please check the new solution? I am using formatToParts method of Intl.DateTimeFormat instance and getting year, month, day, etc. from its result. What do you think? I tried this in my React Native environment and it works perfectly. All tests are passed correctly as well.

[Pareder]

@iamkun Could you please review it?

[KingAmo]

any update on this ?

[artemkhalygov]

@iamkun Please merge this pull request

[jgtorrejon]

Tried applying a patch but still does not work on iOS 😔

[milesingrams]

I didnt see this PR and wrote a similar one that solves the same problem using dayjs to parse the date string. Here is it. Please approve either one of these @iamkun. Pleasssssse! Would hugely appreciate it. We are having to use the patch-package trick to overwrite these lines in our codebase until its fixed.

#2843