Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

toLocaleDateString does not handle zh-CN properly #42030

Closed
FredrikL opened this issue Feb 17, 2022 · 4 comments
Closed

toLocaleDateString does not handle zh-CN properly #42030

FredrikL opened this issue Feb 17, 2022 · 4 comments
Assignees
Labels
i18n-api Issues and PRs related to the i18n implementation.

Comments

@FredrikL
Copy link

FredrikL commented Feb 17, 2022

Version

16.14

Platform

MacOS 12.2.1 & Github Actions linux based runners

Subsystem

icu

What steps will reproduce the bug?

The following script can be used to reproduce

const dateWithTimeOptions = Object.freeze({
  year: 'numeric',
  month: '2-digit',
  day: '2-digit',
  hour: 'numeric',
  minute: 'numeric',
});

const localTime = Date.now();
const str = new Date(localTime).toLocaleDateString('zh-CN', dateWithTimeOptions);
console.log(str);

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior?

Output with 16.13 (expected)
2022/02/17 下午3:42

What do you see instead?

Output with 16.14
2022/02/17 15:42

Additional information

No response

@Mesteery Mesteery added the i18n-api Issues and PRs related to the i18n implementation. label Feb 17, 2022
@richardlau
Copy link
Member

richardlau commented Feb 17, 2022

This is almost certainly due to the update to ICU 70.1 (#41525) which was done to update the timezone information. In previous issues reporting formatting changes it has been stated by people more familiar with ICU that the exact format of locale strings should not be depended upon to remain invariant:

The purpose of the locale strings has always been to attempt to output something that will be readable to people with their own language and cultural preferences. Think of a general user viewing some financial information. As I mentioned, if your documents have a specific requirement, they fall somewhat outside of this.

Ref: #38897 (comment)
cc @nodejs/i18n-api

FWIW adding the hour12 formatting option produces consistent results between 16.14.0 and 16.13.0:

const dateWithTimeOptions = Object.freeze({
  year: 'numeric',
  month: '2-digit',
  day: '2-digit',
  hour: 'numeric',
  minute: 'numeric',
  hour12: true,
});

const localTime = Date.now();
const str = new Date(localTime).toLocaleDateString('zh-CN', dateWithTimeOptions);
console.log(str);

@srl295
Copy link
Member

srl295 commented Feb 17, 2022

@FredrikL specifically, CLDR-10560

consensus was:

For CN, strongly prefer 24-hour time, HH:mm. Many many examples provided to suggest that this now the most common form for times in text (though not necessarily in informal speech)

Definitely use hour12 as suggested to request a specific cycle format, but be aware that it is not considered the recommended cycle for this locale.

@srl295 srl295 self-assigned this Feb 17, 2022
@srl295
Copy link
Member

srl295 commented Feb 17, 2022

FYI (and @richardlau perhaps this could be made more prominent somewhere) : the CLDR project has delta charts, accessible by https://cldr.unicode.org/index/charts - you can see what changed from release to release.

@srl295
Copy link
Member

srl295 commented Apr 4, 2023

not a bug, closing

@srl295 srl295 closed this as not planned Won't fix, can't repro, duplicate, stale Apr 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n-api Issues and PRs related to the i18n implementation.
Projects
None yet
Development

No branches or pull requests

4 participants