fix(moment): use timezone from Hexo config instead of maching settings

[stevenjoezhang]

What does it do?

See hexojs/hexo-front-matter#146

Screenshots

Pull request tasks

• Add test cases for the changes.
• Passed the CI test.

[github-actions]

How to test

git clone -b timezone-dev https://github.com/hexojs/hexo.git
cd hexo
npm install
npm test

[coveralls]

Pull Request Test Coverage Report for Build 20631857379

Details

• 54 of 63 (85.71%) changed or added relevant lines in 6 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.09%) to 99.402%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
lib/hexo/validate_config.ts	15	24	62.5%

Totals
Change from base Build 18971852506:	-0.09%
Covered Lines:	9980
Relevant Lines:	10040

---

💛 - Coveralls

[Copilot]

Pull Request Overview

This PR updates timezone handling to work with the new hexo-front-matter v5.0.0, which now returns dates in UTC format. The changes ensure consistent date handling across the codebase by adjusting for timezone offsets when parsing dates.

Key changes:

• Updated hexo-front-matter dependency from v4.2.1 to v5.0.0
• Modified toDate() and adjustDateForTimezone() functions to handle UTC dates correctly
• Updated all test fixtures to use moment.utc() for consistent timezone handling

Reviewed Changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
package.json	Upgraded hexo-front-matter dependency to v5.0.0
lib/plugins/processor/common.ts	Updated toDate() to adjust for timezone offset and simplified adjustDateForTimezone() logic
lib/plugins/processor/post.ts	Added defaultTimeZone option to yfm() calls and switched to Date.UTC() for date parsing
lib/plugins/processor/asset.ts	Added defaultTimeZone option to yfm() calls
lib/models/types/moment.ts	Updated toMoment() to explicitly set timezone to UTC
lib/hexo/post.ts	Added defaultTimeZone option to yfmParse() call
test/scripts/processors/common.ts	Added DURATION_MINUTE constant and updated test expectations for timezone-adjusted dates
test/scripts/models/moment.ts	Updated tests to use moment.utc() for consistent UTC handling
test/scripts/filters/post_permalink.ts	Updated test fixtures to use moment.utc() and removed unnecessary date fields
test/scripts/console/new.ts	Changed front-matter title format from triple-quoted to double-quoted string

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[yoshinorin]

Since this PR is a potentially breaking change, I think it would be better to include it in the 9.x release rather than a minor version. What are your thoughts?

[stevenjoezhang]

If the user hasn't set a timezone in Hexo's _config.yml, this pull request will cause the generated post timestamps to change. If the user's permalink setting includes time-based parts, it will also change the URLs of their posts.

I think merging it into 8.x or waiting until 9.0 would both be acceptable approaches. We should remind users to properly configure their default timezone, or, let Hexo write the timezone into the configuration file automatically during the first initialization.

[yoshinorin]

I think merging it into 8.x or waiting until 9.0 would both be acceptable approaches. We should remind users to properly configure their default timezone, or, let Hexo write the timezone into the configuration file automatically during the first initialization.

Most users probably have the same timezone set for both their PC and config.yml, so this likely won't be an issue for many users.

That said, I don't think typical users would expect this kind of change to be included in a minor version update. The possibility of URLs changing is particularly concerning (I apologize, I overlooked this aspect).

Therefore, I personally think it would be preferable to release this in a major version.

[yoshinorin]

refs: https://github.com/hexojs/hexo-front-matter?tab=readme-ov-file#timezone-behavior

[yoshinorin]

@stevenjoezhang

I've been thinking about the rollout plan for this feature, and I believe it would be better to ensure backward compatibility and provide advance warnings. Specifically, here's what I suggest:

1. Backward Compatibility Configuration

IMHO, We should provide a configuration option to maintain backward compatibility. For example, we could allow users to specify LocalTimeZone (or similar value) in the timezone setting of _config.yml:

_config.yml
// example
timezone: LocalTimeZone# Uses machine's local timezone (legacy behavior)

When this value is set, Hexo would continue to use the machine's timezone as it does currently, preserving the existing behavior for users who rely on it.

2. Deprecation Warning in Minor Version (v8.x)

Before releasing this feature, we should introduce a deprecation warning in the next minor version (Perhaps v8.2?). How about modifying the validation in 0c60e6f slightly to display warnings in the following cases:

• Display a warning when timezone is not explicitly configured in _config.yml
• Inform users that the behavior will change in Next major version (Perhaps v9.0)
• Recommend that users who want to maintain the current behavior should explicitly set timezone: LocalTimeZone in _config.yml, otherwise they should configure a specific timezone

3. Full Implementation in Next major version (Perhaps v9.0)

IMHO, The actual breaking changes (excluding the warning) should be released inv9.0.

---

How do you think?

[stevenjoezhang]

@yoshinorin Updated in cad9c2a

• Support Backward Compatibility Configuration: timezone: LocalTimeZone and Recommend that users who want to maintain the current behavior should explicitly set timezone: LocalTimeZone in _config.yml, otherwise they should configure a specific timezone
• Display a warning when timezone is not explicitly configured in _config.yml
• Inform users that the behavior will change in Next major version

[yoshinorin]

@stevenjoezhang

Recommend that users who want to maintain the current behavior should explicitly set timezone: LocalTimeZone in _config.yml, otherwise they should configure a specific timezone

I think this warning should be displayed to all users, regardless of whether _config.yml has the timezone setting or what value is configured.

Also, if we merge the current implementation as-is, users' generated output could change without them seeing the warning. Therefore, I was thinking we should create a separate PR for just the warning part, merge only that, and release it first (probably in v8.2.0). What do you think? (Sorry if there was a misunderstanding due to my unclear explanation, or if I'm mistaken...)

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

OpenSSF Scorecard

Package	Version	Score	Details
npm/yaml	2.7.1	🟢 7.2	Details Check Score Reason Security-Policy 🟢 10 security policy file detected Maintained 🟢 10 14 commit(s) and 6 issue activity found in the last 90 days -- score normalized to 10 Code-Review ⚠️ 0 Found 0/11 approved changesets -- score normalized to 0 Dangerous-Workflow 🟢 10 no dangerous workflow patterns detected Packaging ⚠️ -1 packaging workflow not detected Token-Permissions 🟢 9 detected GitHub workflow tokens with excessive permissions Binary-Artifacts 🟢 10 no binaries found in the repo CII-Best-Practices ⚠️ 0 no effort to earn an OpenSSF best practices badge detected Pinned-Dependencies ⚠️ 2 dependency not pinned by hash detected -- score normalized to 2 License 🟢 10 license file detected Fuzzing 🟢 10 project is fuzzed Branch-Protection 🟢 3 branch protection is not maximal on development and all release branches Signed-Releases ⚠️ -1 no releases found SAST 🟢 10 SAST tool is run on all commits
npm/hexo-front-matter	5.0.0	🟢 3.1	Details Check Score Reason Maintained ⚠️ 0 0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0 Packaging ⚠️ -1 packaging workflow not detected Code-Review 🟢 7 Found 16/21 approved changesets -- score normalized to 7 Binary-Artifacts 🟢 10 no binaries found in the repo Dangerous-Workflow 🟢 10 no dangerous workflow patterns detected Pinned-Dependencies ⚠️ 0 dependency not pinned by hash detected -- score normalized to 0 Token-Permissions ⚠️ 0 detected GitHub workflow tokens with excessive permissions CII-Best-Practices ⚠️ 0 no effort to earn an OpenSSF best practices badge detected License ⚠️ 0 license file not detected Fuzzing ⚠️ 0 project is not fuzzed Signed-Releases ⚠️ -1 no releases found Branch-Protection ⚠️ 0 branch protection not enabled on development/release branches Security-Policy ⚠️ 0 security policy file not detected SAST ⚠️ 0 SAST tool is not run on all commits -- score normalized to 0
npm/luxon	3.7.2	🟢 3.7	Details Check Score Reason Maintained 🟢 5 2 commit(s) and 4 issue activity found in the last 90 days -- score normalized to 5 Code-Review 🟢 3 Found 11/30 approved changesets -- score normalized to 3 Dangerous-Workflow 🟢 10 no dangerous workflow patterns detected Packaging ⚠️ -1 packaging workflow not detected Token-Permissions ⚠️ 0 detected GitHub workflow tokens with excessive permissions Binary-Artifacts 🟢 10 no binaries found in the repo CII-Best-Practices ⚠️ 0 no effort to earn an OpenSSF best practices badge detected Security-Policy ⚠️ 0 security policy file not detected Pinned-Dependencies ⚠️ 2 dependency not pinned by hash detected -- score normalized to 2 License 🟢 10 license file detected Fuzzing ⚠️ 0 project is not fuzzed Branch-Protection ⚠️ 0 branch protection not enabled on development/release branches Signed-Releases ⚠️ -1 no releases found SAST ⚠️ 0 SAST tool is not run on all commits -- score normalized to 0

Scanned Files

• package-lock.json

[yoshinorin]

LGTM 👍