You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by "vasiliy-mikhailov (via GitHub)" <gi...@apache.org> on 2026/06/26 20:01:59 UTC
[PR] Compute the Snowflake epoch in UTC instead of the system timezone [shardingsphere]
vasiliy-mikhailov opened a new pull request, #38932:
URL: https://github.com/apache/shardingsphere/pull/38932
The static `EPOCH` for `2016-11-01 00:00:00` is converted to epoch millis using the JVM's **default timezone** offset (`ZoneId.systemDefault()...getOffset(Instant.now())`). The Snowflake key timestamps therefore shift with the server's timezone, which can cause duplicate or mis-ordered keys across deployments in different zones. Use `ZoneOffset.UTC` so the epoch is timezone-independent.
Added a test (run under `-Duser.timezone=Asia/Shanghai`) asserting the epoch equals the UTC-based value.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Compute the Snowflake epoch in UTC instead of the system timezone [shardingsphere]
Posted by "terrymanu (via GitHub)" <gi...@apache.org>.
terrymanu merged PR #38932:
URL: https://github.com/apache/shardingsphere/pull/38932
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Compute the Snowflake epoch in UTC instead of the system timezone [shardingsphere]
Posted by "vasiliy-mikhailov (via GitHub)" <gi...@apache.org>.
vasiliy-mikhailov commented on PR #38932:
URL: https://github.com/apache/shardingsphere/pull/38932#issuecomment-4821384305
Thanks @linghengqian. The added `SnowflakeKeyGenerateAlgorithmTest#assertEpochShouldBeTimezoneIndependent` is the minimal reproducer, and it's deterministic rather than timing-based: it asserts the configured EPOCH equals `LocalDateTime.of(2016, 11, 1, 0, 0, 0).toInstant(ZoneOffset.UTC).toEpochMilli()` (the fixed UTC epoch), regardless of the JVM default timezone. On master the EPOCH is parsed in the system timezone, so the test fails whenever the default zone isn't UTC (e.g. `-Duser.timezone=America/New_York`); with the fix it passes in any zone. Since it compares the computed epoch constant, not clock skew, it doesn't need a `max-tolerate-time-difference-milliseconds` tolerance. CI (checkstyle) is fixed now too.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Compute the Snowflake epoch in UTC instead of the system timezone [shardingsphere]
Posted by "vasiliy-mikhailov (via GitHub)" <gi...@apache.org>.
vasiliy-mikhailov commented on PR #38932:
URL: https://github.com/apache/shardingsphere/pull/38932#issuecomment-4821383993
Done, thanks. Removed the two unused imports (`java.time.Instant`, `java.time.ZoneId`); `./mvnw checkstyle:check -Pcheck` is clean now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Compute the Snowflake epoch in UTC instead of the system timezone [shardingsphere]
Posted by "terrymanu (via GitHub)" <gi...@apache.org>.
terrymanu commented on PR #38932:
URL: https://github.com/apache/shardingsphere/pull/38932#issuecomment-4816217711
Please fix checkstyle first
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Compute the Snowflake epoch in UTC instead of the system timezone [shardingsphere]
Posted by "vasiliy-mikhailov (via GitHub)" <gi...@apache.org>.
vasiliy-mikhailov commented on PR #38932:
URL: https://github.com/apache/shardingsphere/pull/38932#issuecomment-4828723213
Thanks for the thorough review, both points addressed.
1. Timezone test: since EPOCH is a static final computed at class load, a test-level TimeZone.setDefault cannot reliably control it (the class may already be loaded by an earlier test in the JVM). I added a scoped Surefire user.timezone=Asia/Shanghai to the snowflake module pom, which forces a non-UTC default for the whole test JVM before the class loads. Verified locally: with this override the test passes on the new UTC-based code, and fails on the previous implementation (Expected: is <1477958400000L>, the old offset-based value is 8 hours off), so it is now a real regression regardless of the runner timezone.
2. Release notes: added a 5.5.4 Bug Fixes entry for the UTC epoch change. Note for users: non-UTC deployments will see different generated key values after upgrading, since the epoch baseline shifts to UTC.
Pushed both.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Compute the Snowflake epoch in UTC instead of the system timezone [shardingsphere]
Posted by "vasiliy-mikhailov (via GitHub)" <gi...@apache.org>.
vasiliy-mikhailov commented on PR #38932:
URL: https://github.com/apache/shardingsphere/pull/38932#issuecomment-4851451333
Good catch, thanks. You are right that the module argLine was replacing the inherited jdk11+ flags instead of extending them. I moved the timezone into the argLine property so it composes with the parent Surefire config: the effective argLine now keeps the four --add-opens entries and -XX:+EnableDynamicAgentLoading and appends -Duser.timezone=Asia/Shanghai. Verified locally: the focused Snowflake test passes with no dynamic-agent warning (flags present), and it still fails on the pre-fix implementation (the timezone guard is intact). Pushed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org