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.

[Copilot]

[nitpick] The comment on lines 128-130 mentions 'It will be corrected by invoking adjustDateForTimezone later', but this creates a dependency between two separate code blocks (here and line 140). Consider adding a reference to the specific line where the correction happens (e.g., 'It will be corrected on line 140 by invoking adjustDateForTimezone') to make the relationship more explicit.

[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