Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix($shared-utils): fix date parse logic for permalinks #2181

Merged
merged 1 commit into from
Aug 23, 2020
Merged

fix($shared-utils): fix date parse logic for permalinks #2181

merged 1 commit into from
Aug 23, 2020

Conversation

enagic
Copy link
Contributor

@enagic enagic commented Feb 13, 2020

This addresses the way the date string is parsed, which is causing the input for the Date constructor to assume the date to be in ISO 8601 format (UTC). This results in the generated permalink to be one day off (depending on your local timezone).

Example:
new Date('2020-01-01') results in the date being parsed as Tuesday, December 31, 2019 19:00:00 GMT-0500 for EST.

new Date('2020-1-01') results in the date being parsed as Wednesday, January 01, 2020 00:00:00 GMT-0500 for EST.

As noted in developer.mozilla.org

Note: Parsing of date strings with the Date constructor (and Date.parse(), which works the same way) is strongly discouraged due to browser differences and inconsistencies.

Summary

What kind of change does this PR introduce? (check at least one)

  • Bugfix
  • Feature
  • Code style update
  • Refactor
  • Docs
  • Build-related changes
  • Other, please describe:

If changing the UI of default theme, please provide the before/after screenshot:

Does this PR introduce a breaking change? (check one)

  • Yes
  • No

If yes, please describe the impact and migration path for existing applications:

This will change the logic used for existing permalinks, possibly offsetting the published date by 1 day.

The PR fulfills these requirements:

  • When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)

You have tested in the following browsers: (Providing a detailed version will be better.)

  • Chrome
  • Firefox
  • Safari
  • Edge
  • IE

If adding a new feature, the PR's description includes:

  • A convincing reason for adding this feature
  • Related documents have been updated
  • Related tests have been updated

To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.

Other information:

@enagic enagic requested review from billyyyyy3320 and ulivz and removed request for billyyyyy3320 February 13, 2020 23:58
Copy link
Collaborator

@billyyyyy3320 billyyyyy3320 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, where did you meet this problem? Could you provide a repro?

Since I tested the function and saw the behavior of new Date, but I also found that our current code (with getMonth and getDate) somehow work fine.

@enagic
Copy link
Contributor Author

enagic commented Feb 14, 2020

It might be difficult for you to validate the issue without resetting your clock since you might not have too much delta between your local timezone and UTC.

The Mozilla website from the link above also says...

Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.

@billyyyyy3320
Copy link
Collaborator

Well, my local timezone is UTC+8, so here is what I met:

const date = new Date("2020-1-1");   // I got: 2019-12-31T16:00:00.000Z
const month = date.getMonth() + 1;   //  I got: 1
const day = date.getDate(); // I got: 1

Obviously, the date is inconsistent as you said. However, something like getMonth and getDate looks totally fine and we are using them to get our permalink.

That's why I wish you can link me where you met the problem.

@enagic
Copy link
Contributor Author

enagic commented Feb 14, 2020

Oh, I got ya. I thought you were asking which branch had the issue. I don't have anything pushed in Github to demo, but I was getting the issue from version 1.3.0, if that helps.

I'm surprised new Date("2020-1-1") gave you 2019-12-31.

Here are my results:

const d1 = new Date('2020-01-01'); // Tue Dec 31 2019 19:00:00 GMT-0500 (Eastern Standard Time)
const d2 = new Date('2020-1-1'); // Wed Jan 01 2020 00:00:00 GMT-0500 (Eastern Standard Time)

d1.getMonth() + 1; // 12
d1.getDate(); // 31

d2.getMonth() + 1; // 1
d2.getDate(); // 1

The effect was that, though my .md file was _posts/2019-02-11/hello-world/index.md, the permalink that was generated was /2019-02-10-hello-world/index.html.

@kefranabg
Copy link
Collaborator

Hey, what should we do about this PR? @enagic if we're not able to reproduce we'll close this PR

@enagic
Copy link
Contributor Author

enagic commented Feb 24, 2020

And here I thought, "Well it works fine in my local environment" wasn't a valid QA response!

But in all seriousness, I suspect the first step to reduce should be to reset your local clock to a different timezone. In my case, it's EST.

@haoranpb
Copy link
Contributor

I can indeed reproduce it after I set my timezone to EST: repo

This addresses the way the date is parsed, which, when it's a string is causing the input for the Date constructor to assume the date to be in ISO 8601 format (UTC), and when it's a Date, is always UTC.
Copy link
Collaborator

@billyyyyy3320 billyyyyy3320 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. At least one more 'Approve', it'll be merge.

@enagic
Copy link
Contributor Author

enagic commented May 8, 2020

Do we still want to have this merged?

@newsbielt703, @ulivz, @kefranabg

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants