[Development] Calendar Systems proposal
robin.burchell at crimson.no
Mon Jan 30 22:03:23 CET 2017
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");
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.
> > Have you considered whether Date.prototype.toLocaleDateString could be
> > of use for this? See:
> Date.prototype.toLocaleDateString is used to converting date to a string
> bases on a Locale. 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(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:
If you want to see it in action, in a browser, try something like this
in a web browser JS console:
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
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.
> 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?
robin at crimson.no
More information about the Development