[Development] Calendar Systems proposal

[Edward Welbourne]

Sorry to have left this thread dangling for so long.
A vast flood of code-review came my way ...
Now to work my way back through the thread, staring at the end,
so all in JavaScript land:

On Mon, Jan 30, 2017, at 09:07 PM, Hamed Masafi wrote:
>> My prefer option is form (3)
>> We can add an enumeration to global space.
>> var date = new Date;
>> var out = date.toString(Qt.JalaliCalendar, "yyyy-MM-dd");

Robin Burchell (30 January 2017 22:03) replied:
> I would prefer to not modify standard APIs if we can avoid it (unless we
> have a good reason to do so and such a change is pretty low risk).
> Keeping close to the rest of the JS ecosystem means that skills learned
> in one place are easily translated to another (meaning less
> QJSEngine-specific knowledge and docs are required). In the particular
> case of Date.prototype.toString(), it also means that should any future
> specification start supporting additional arguments there, we aren't
> going to open ourselves up to future unexpected problems.

Indeed; we should keep our ECMAScript (i.e. JavaScript) implementation
as clean as we can.  If we *do* want to extend, we should do it via
properties of the Qt object, not the global object.  So

  var date = new Date;
  var out = Qt.Calendar('Jalali').dateToString(date, 'yyyy-MM-dd')

would be a more apt model for what to aim for.

>> > Have you considered whether Date.prototype.toLocaleDateString could be
>> > of use for this? See:
>> >
>> http://ecma-international.org/ecma-402/3.0/index.html#sup-date.prototype.tolocaledatestring
>> Date.prototype.toLocaleDateString is used to converting date to a string
>> bases on a Locale.

and, just to be clear here, a Locale is a string or list of strings, not
to be confused with one of Qt's locale objects, although V4 does in fact
accept one of *those* - in violation of the ECMA spec (see below).

>> we can use this function for accepting an CalendarType
>> (CalendarType is a QEnum that contains list of calendar types like;
>> gregorian, jalali, hindi or etc)
>> date.toLocaleString(format);
>> date.toLocaleString(CalendarType, format);
>> date.toLocaleString(locale, format);
>> date.toLocaleString(CalendarType, locale, format);

> Right, if you look at the spec I linked you to, that's what it
> specifies- converting a date to a string in a locale-specific way. They
> don't use an enum, but a string to describe the calendar system (plus
> some additional options to control the formatting result in an
> additional optional parameter). I can admit the spec is a bit hard to
> read. Here's a slightly less formal description, with some examples:
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString

Thanks for that.  I'd read the spec and been left none the wiser.  So we
should expect the locale argument to be a string (or an array of
strings, each of) which looks like a language code (hyphen-joined
sequence of tokens) and may include -u-ca-... tokens indicating a
selection of calendar.  So

  var out = date.toLocaleDateString('ar-EG-u-ca-persian')

should also be suitable.

> If you want to see it in action, in a browser, try something like this
> in a web browser JS console:
>
>     console.log(new Date().toLocaleDateString("ar-EG"))
>
> I see:
>
>     ٣٠‏/١‏/٢٠١٧
>
> Which I hope is something useful/meaningful, I'm unfortunately not
> familiar enough with that locale to tell. I've confirmed this to work in
> recent releases of Safari, Firefox and Chrome on OS X. Outside of
> browsers, YMMV. I didn't get Nodejs to respect the locale options, for
> instance.
>
> What we implement now is nothing close to this (in fact, we simply
> ignore all arguments and return the argument using local formatting) -
> my guess is that it is down to most of this being added after ES5.

ECMA-262 explicitly forbids [*] extending toLocaleString(),
toLocaleTimeString() and toLocaleDateString() in any way other than as
described in ECMA-402, which adds the locale and options.  So we conform
to the old spec in so far as we ignore the parameters (but see
QTBUG-56923; for whose worst deviations I have a partial fix awaiting
review).

[*] http://www.ecma-international.org/ecma-262/7.0/index.html#sec-forbidden-extensions

>> But there are some bugs related to this prototype, We have to solve that
>> within this process.

> As I said, as it stands, our implementation is currently not doing what
> you need - it would need to be fleshed out to actually use the provided
> arguments. However, I think that extending this seems to be a pretty
> good match for the functionality you are wanting to add?

That's also my impression; if we implement ECMA-402's locale extensions,
including calendar support, I think we get most of the way to what
Soroush and Hamed are after.  We just need the infrastructure in Qt on
which to build the V4 extensions (conformant to ECMA-402).
For which I need to answer earlier mails ...

	Eddy.