-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Intl: new Date().toLocaleString('de') puts unicode (BiDi) markers around punctuation #599
Comments
If you don't mind, I'd like to make it a personal exercise to fix this bug with a PR. So far I've got chakra to build. Its amazing how easy it was. I see the baseline tests and I'll spend some time this weekend to get this fixed and make sure I don't break anything else. |
This isn't a RegExp issue. It looks like we put LEFT-TO-RIGHT MARK (U+200E) around punctuation marks, but Chrome and Firefox don't. On Edge: var d = new Date("2016-03-17T21:43:10.645Z").toLocaleString('de');
d === "17.03.2016 14:43:10";
d[1] === "1";
d[2] === "7";
d.charCodeAt(3) === 8206;
d[4] === ".";
d.charCodeAt(5) === 8206;
d[6] === "0"; On Chrome: var d = new Date("2016-03-17T21:43:10.645Z").toLocaleString('de');
d === "17.3.2016 14:43:10";
d[0] === "1";
d[1] === "7";
d[2] === ".";
d[3] === "3"; I don't know why we have the "LEFT-TO-RIGHT MARK (U+200E)" around punctuation marks though. |
Yeah that's what I just noticed. d = new Date().toLocaleString();
WScript.Echo(d);
I'll change the title of the bug. |
Could this be an issue in the windows GetDateFormatW ? How do I start ch.exe on a file and break it so I can attach a debugger? I don't see a debugging page.
|
If you're using Visual Studio, you can just set the command line parameters for ch by right clicking on the ch project, and setting the appropriate field under the Debugging Configuration Property. Then, set your breakpoints in VS, hit F5 and have fun. |
From what I gather, it seems, some of the logic is in Intl.js. This is probably byte code generated and I don't seem to figure out where the implementation of formatDateTime is. I got debugging to work. I added a 10 sec sleep so I could attach VS.
The breakpoint doesn't seem to hit GetDateLocaleString as I previously hypothesized.
I'm just beginning to realize how complicated chakra can be. |
you might want to break at JavascriptDate::EntryToLocaleDateString and continue from there. |
According to the ECMAScript spec, the string returned by There is an ongoing discussion on how to align implementations and standardize the use of BiDi control characters in the spec. We've decided to postpone the work on this issue until an agreement is reached as part of the standardization discussion. @nojvek, if I understand correctly, you're trying to get the localized time string. Would |
@bterlson Any word on the TC39 Consensus aspect of this issue? |
@dilijev No word, no progress, and it seems unlikely to make progress from my conversations with people. |
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/11907540/ is a duplicate of this bug. |
I've created a test example to address possibly related issues:
|
I see that there's a comma between the date and the time. Also allowed per spec, but the difference is noted.
Already tracked in #3096 |
Tracking as part of #3644 |
I'm not sure if this should be fixed FWTW. Intl operations are by design supposed to be opaque and no expectations should be made as to the output. Bidi marks are perfectly valid parts of the result string and any operations that are attempting to retrieve data from the formatted string (like the regexp in comment 0) are working against the logic of Intl operations. My recommendation would be to close this issue as invalid. |
Sure, but it's horribly inconsistent between browsers. Regex on dates is
something that developers do all the time. Weird hidden characters have
definitely driven me away from Edge.
…On Wed, Dec 20, 2017 at 1:46 PM, Zibi Braniecki ***@***.***> wrote:
I'm not sure if this should be fixed FWTW. Intl operations are by design
supposed to be opaque and no expectations should be made as to the output.
Bidi marks are perfectly valid parts of the result string and any
operations that are attempting to retrieve data from the formatted string
(like the regexp in comment 0) are working against the logic of Intl
operations.
My recommendation would be to close this issue as invalid.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#599 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA-JVP1TLEimqutVrwnC58T5i1-2qGECks5tCYAegaJpZM4HzYLg>
.
|
They're only weird if you are unfamiliar with the issues of bidirectionality. Bidi chars are needed and we will be adding them. "Developers" also tend to do other bad practices like sync io. I don't believe that ignorance in the subject someone is working on is a good reason to sacrifice the quality of the API. |
At this point I'm with keeping the bidi because parsing the output has enough other problems and focusing on TC39 date improvements to get pat today's kludges. |
The text was updated successfully, but these errors were encountered: