toLocaleDateString format and timezone

[homeofclark]

Format a date to a specific format and timezone.
Code:
var d = new Date().toLocaleDateString('zh-Hans-CN', {timeZone: 'America/Denver', hour12: false });
Results:
JS: d= 2018/11/26
Jint: d= Monday, November 26, 2018

[sebastienros]

Didn't even know that was a thing ...

[lahma]

Curiously the array functions branch also has a problem getting Array.toLocaleString right for booleans, might be realted...

[sebastienros]

https://www.ecma-international.org/ecma-402/1.0/#sec-13.3.2

[Ghostbird]

How do I stringify a Date object in a specific time zone using Jint?

The user has to pick a time, but times show up in the server time zone. I know the user IANA time zone. How can I get the UTC offset of the end-user's time zone in Jint? Once I have that, I can calculate the rest.

[LuisMerinoP]

How do I stringify a Date object in a specific time zone using Jint?

I think Jint parses Dates using the host's locale/culture, being the host is where Jint is running.

There is quite a lot of work in all the internationalization side to make it work according to the standard related to:

• Standarization/canonalization for the argument's functions can take (locales and options).
• Logic behind to achieve the best available language to meet the parsing request.

I think almost, if not all of this AbstractOperations need implementation.
As it was done for other cases, we can just imitate JS behaviour bypassing the standard for the widest used cases and cultures. This is a shortcut but can do the job for most cases while meeting the standard is in progress.

I can give this a shot and provide a PR and tests when I find some time. Would that make sense @lahma ?
My concern here is that it might be comfortable to bypass the standard and fix tests here and there but then it might get difficult later to track what is working under the standard and what is not. Moreover, maybe maintainers would prefer the long track and focus the effort in having the abstract operations implemented and meet the standard.

[lahma]

Generally I'd prefer using the test suite to strive towards expected behavior so we don't need to do it twice (say it's implemented to output X and spec says Y and we don't catch it). When opening new set of tests in test suite we can always add ignore rules that will work as TODO list.

Otherwise everything needs to be tested against NodeJS and check what output is produced with some input and build test suite manually based on that. But in the other hand, whatever takes things forward and makes it possible for the community to contribute is great too....