-
-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Date & Timezone issue related with Front-Matter #4548
Comments
cc @yoshinorin @itszero @stevenjoezhang @curbengh So far I just assume those issues were caused by their machines' timezones are inconsistent with their hexo configurations. |
+1, Hexo shouldn't need to query the host machine's timezone, There is still a need to query host's timezone since Another complication is that it is also possible to specify timezone in front-matter, e.g. Perhaps we can prioritise like this:
|
It appears that there is no way we could get the timezone name directly (If so, we could use it as a default value during hexo config processing). The only thing we get is |
We can use JavaScript built-in object Intl.DateTimeFormat().resolvedOptions().timeZone
// UTC
// Asia/Tokyo
// etc. We can use it for the default timezone in config. |
Check List
Please check the following before submitting a new issue.
hexo version
to check)The issue has been reported in
For example, I have a post setup as following:
Also, my machine is under the
Asia/Shanghai
timezone, which will also affect Node.js' timezone.After the front-matter being processed by
js-yaml
, the "Date-like string" will be converted intoDate
object:Notice that the input was converted into the UTC? Users will only fill in the front-matter with their local time, not the UTC. Thus it is not the desired behavior.
So during the processing of front-matter,
Date#getTimezoneOffset
has been used:It will result in:
Which is the desired behavior.
Then, during the processing pf posts,
moment.timezone
was used:hexo/lib/plugins/processor/post.js
Lines 80 to 82 in 557487a
hexo/lib/plugins/processor/common.js
Lines 51 to 60 in 557487a
If the
config.timezone
is configured correctly, there will be no differences between before and aftertimezone()
:A demo can be found here: https://runkit.com/sukkaw/5f732261a7aac8001a42bcc4
So, what about a different timezone environment? For example, the CI environment. Its timezone will not be
Asia/Shanghai
.So here is another demo: https://repl.it/repls/LividBewitchedControlflowgraph#index.js
As you can see,
Date after calculating the timezone offset
is now wrong, whileDate after moment-timezone
is still correct. That's becausetimezone()
takesgetTimezoneOffset
into consideration.So, what about removing "getTimezoneOffset" completely?
Here goes
Date after moment-timezone (without pre offset)
. It is generated without usingDate#getTimezoneOffset
, and the result is still correct. It also means it is not affected by the environment (no `Date#getTimezoneOffset being used).By eliminating the Node.js timezone affection (only dependents on users'
config.timezone
configuration) the timezone issue should be solved.The text was updated successfully, but these errors were encountered: