Chrome与Safari中无参toLocaleTimeString()行为差异及原因问询

Great question! Let's unpack exactly why you're seeing these inconsistencies, starting with what MDN means when it says the parameterless toLocaleTimeString() depends on implementation, locale, and time zone.

What Does "Depends on Implementation, Locale, and Time Zone" Mean? #

When you call new Date().toLocaleTimeString() without arguments, the method doesn't follow strict, universal rules for formatting time. Instead:

• Locale: It uses your system's default locale (or the browser's configured locale if it overrides system settings). This includes cultural conventions like 12-hour vs 24-hour clocks, AM/PM labeling, and separator styles.
• Time Zone: It converts the Date object's underlying UTC time to your system's local time zone before formatting.
• Implementation: The ECMAScript standard doesn't dictate an exact output format—browser vendors get to interpret the locale's conventions as they see fit. So even with the same locale, two browsers might pick different default formats.

Breaking Down Your Test Results #

Let's walk through your specific Mac-based scenario step by step:

Initial Setup: System Locale = English (India) #

• Chrome (87.0.4280.88): Returns 16:57:37 (24-hour format).
  Chrome's implementation for English (India) defaults to 24-hour time, which is a widely used convention in many parts of India, even though 12-hour format is also common.
• Safari (14.0): Returns 4:57:37 PM (12-hour format).
  Safari's implementation prioritizes 12-hour time for English (India). This is a valid browser-specific choice—since the standard doesn't enforce one format over the other, Apple likely made this call based on their interpretation of regional user preferences.

After Changing Locale to English (US) & Restarting Chrome #

Chrome starts returning 4:57:37 PM because English (US) has a strong, universal default of 12-hour time with AM/PM labels. Chrome requires a restart to fully pick up system locale changes, which is why you saw the shift only after rebooting the browser.

Why Safari Used 12-Hour Time in English (India) From the Start? #

This comes down to browser-specific implementation logic. Safari might be reading more granular system settings (like the "Time Format" sub-preference under Language & Region) instead of just the top-level locale, or it has internal defaults for certain locales that differ from Chrome. Since the standard doesn't mandate a single "correct" format, both browsers are behaving within the rules—they just made different choices for default presentation.

How to Avoid This Inconsistency #

If you need a consistent time format across all browsers and system settings, always pass explicit arguments to toLocaleTimeString(). For example:

• Force 12-hour format:

  new Date().toLocaleTimeString('en-US', { hour12: true })
  

• Force 24-hour format:

  new Date().toLocaleTimeString('en-US', { hour12: false })
  

You can also specify a precise locale (like 'en-IN' for English India) alongside format options to lock in regional conventions and eliminate guesswork.

内容的提问来源于stack exchange，提问作者prashanth