fix(rc): Set explicit English locale for date parsing

[jungsehui]

Fixes #1196

Discussion

• This PR addresses the date parsing issue reported in [BUG] RemoteConfig unit tests fail in non-English (e.g., Korean) Locales due to Date Parsing #1196 where SimpleDateFormat fails or misbehaves in non-English locales (e.g., Korean).

Testing

• Verified that all existing unit tests and integration tests pass on my local machine (mvn test).
• Verified that the linters pass (mvn validate).
• Specifically tested with JVM arguments -Duser.language=ko -Duser.country=KR to ensure the RemoteConfigUtil now safely handles RFC 1123 and Zulu dates regardless of the host OS locale.

API Changes

• No public API changes. This only modifies internal implementation details within RemoteConfigUtil.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical bug where date parsing in RemoteConfigUtil was locale-dependent, leading to failures in non-English environments. By enforcing an English locale for date formatting and parsing, the utility now provides consistent and reliable date handling across all operating system locales, improving robustness for international users.

Highlights

• Bug Fix: Resolved a critical date parsing issue in RemoteConfigUtil where SimpleDateFormat misbehaved in non-English locales, specifically reported in issue [BUG] RemoteConfig unit tests fail in non-English (e.g., Korean) Locales due to Date Parsing #1196.
• Locale Enforcement: Explicitly set Locale.ENGLISH for all SimpleDateFormat instances within RemoteConfigUtil to ensure consistent and reliable parsing of RFC 1123 and Zulu dates, regardless of the host operating system's locale.
• No API Changes: The fix involves only internal implementation details and introduces no changes to the public API.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly fixes a date parsing issue that occurs in non-English locales by explicitly setting Locale.ENGLISH when creating SimpleDateFormat instances. This resolves the immediate bug. I've also added a suggestion to modernize the code by migrating from the legacy SimpleDateFormat to the thread-safe java.time.DateTimeFormatter API, which would improve code quality and performance.

[gemini-code-assist]

While adding Locale.ENGLISH fixes the immediate bug, SimpleDateFormat is an outdated and mutable API. Since this project supports Java 8+, it's highly recommended to migrate to the modern java.time API for date and time operations.

java.time.format.DateTimeFormatter is immutable and thread-safe. This means you can define formatters as static final constants and reuse them without needing ThreadLocal or synchronization. This makes the code cleaner, safer, and more performant.

For example, this method could be rewritten as:

// At class level:
private static final DateTimeFormatter ZULU_DATE_FORMATTER =
    DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSSSSSSS'Z'")
        .withZone(ZoneOffset.UTC);

// In convertToUtcZuluFormat method:
static String convertToUtcZuluFormat(long millis) {
    checkArgument(millis >= 0, "Milliseconds duration must not be negative");
    return ZULU_DATE_FORMATTER.format(Instant.ofEpochMilli(millis));
}

The original pattern yyyy-MM-dd'T'HH:mm:ss.SSS000000'Z' is correctly implemented with java.time's yyyy-MM-dd'T'HH:mm:ss.SSSSSSSSS'Z'. A similar refactoring can be applied to the other date utility methods in this class. For UTC_DATE_PATTERN, you can even use the pre-defined DateTimeFormatter.RFC_1123_DATE_TIME.

[jungsehui]

Thanks for the suggestion, @gemini-code-assist!

While migrating to java.time.DateTimeFormatter is definitely a great modernization step for thread safety and performance, I opted to stick with SimpleDateFormat and simply add Locale.ENGLISH for this specific PR.

My intention was to keep the bug fix as minimal and safe as possible without changing the underlying API or expanding the scope of the PR (especially regarding the manual fractional seconds handling currently implemented in the methods).

I'm happy to update this to DateTimeFormatter if the maintainers prefer that approach! Let me know.

[gemini-code-assist]

Thanks for explaining your reasoning, jungsehui. Your approach to keep the bug fix minimal and safe by adding Locale.ENGLISH to SimpleDateFormat instances is perfectly valid and effectively addresses the reported issue. This ensures the immediate problem is resolved without introducing broader changes.

While migrating to java.time.DateTimeFormatter is indeed a recommended modernization step for its thread-safety and improved API, it's understandable to defer such a refactoring to a separate pull request to maintain the focused scope of this bug fix. The current changes are good to go for resolving issue #1196.