Re: [Development] Calendar Systems proposal
On Tuesday, 8 August 2017 08:49:36 PDT Edward Welbourne wrote:
> Thiago Macieira (7 August 2017 06:14)
>
> > ... there are bigger problems with the implementation, starting with
> > QAbstractCalendar having a static protected QMap member.
>
> That's my fault. We're going to need some way for QML/V4 to get at
> calendars; and I want to ensure our design leaves scope for client code
[cut]
>
> Please suggest a better solution (and explain the problem with the
> present solution), either here or in the review.
The problem is the presence of a protected, static, non-POD member. Remove it.
Store the data in a Q_GLOBAL_STATIC in qabstractcalendar.cpp. If you need to
get a listing or do any kind of searching, add static functions to
QAbstractCalendar. See QTextCodec for inspiration.
> > The big problem is how you've implemented the new API in QDateTime and
> > QLocale. There's code duplication that cannot be there in QLocale,
>
> That's probably best addressed by you commenting on the review; I'm not
> sure what duplication you're referring to ("cannot be there" is strong
> language), although I do know about dateTimeToString(). There are a few
> places I expect to find myself doing clean-up in the aftermath of
> getting this all in, but I don't mind doing some of it before-hand.
The big code block that was added in the commit to qlocale.cpp looks like a
copy & paste of existing code.
> Note, also, that this moves calendar-related data out of QLocale's
> CLDR-derived data blob into calendar-specific data blobs - a step in the
> general direction of making QLocale less monolithic.
That's good.
> > but the way you've removed the duplication in QDateTime also needs
> > changing for performance reasons.
> >
> > int QDate::year() const
> > {
> > return year(QGregorianCalendar());
> > }
> >
> > This creates a polymorphic object and makes a call that ends up delegating
> > to it in
> >
> > if (cal.julianDayToDate(jd, y, m, d))
>
> Please elaborate: why is this a problem ? The Gregorian arithmetic
> naturally belongs in a calendar implementation. The date-time code
> should naturally call it, rather than duplicating it in static functions
> of its own (which have, naturally, been moved to become its methods).
The problems are:
- creating a polymorphic type (QGregorianCalendar) [performance]
- passing it by reference instead of a pointer [coding style]
- calling a non-inline function to do the calculation [performance]
The performance problems are due to performance regressions. I'd rather you
inverted the deduplication: let QDate have the calculation and call that from
QGregorianCalendar.
> > The commit also includes changes that look like unrelated clean-ups and
> > will need to be split into different commits.
>
> Please point these out on the review. Some of them might not be as
> unrelated as you think - I did a fair bit of pulling separable changes
> out already, rebasing Soroush's work onto the results. I may well have
> missed some, but there were bits that couldn't be separated.
I will.
> > It's at this point lacking documentation
>
> Indeed, there remains work to be done. On the other hand, deciding what
> shape the API should be is worth doing before taking pains over
> documenting every detail - that would all change if we decide we need to
> change the API.
Sure. I just replied here because it looked like it was a request to make it
before the FF.
>
> > and there are a couple of coding style mistakes.
>
> Please note in Gerrit.
s/\w& / &/g
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Thiago Macieira (7 August 2017 06:14)
> ... there are bigger problems with the implementation, starting with
> QAbstractCalendar having a static protected QMap member.
That's my fault. We're going to need some way for QML/V4 to get at
calendars; and I want to ensure our design leaves scope for client code
to provide a calendar of its choice - e.g. so that a developer whose
target market uses a relatively obscure calendar can support them with a
minimum of pain, without Qt itself needing to contain code for every
calendar that ever has been or will be invented. (Conversely, of
course, it's also worth making it easy to configure which, of the
calendar implementations present in Qt, actually get compiled into any
given build.) Each calendar implementation needs a way to make itself
visible to QML/V4.
My naive idea for how to solve that was to let each calendar
implementation register a factory for its objects under a name
representing its calendar. Then QML/V4 (and, for that matter, C++ APIs)
can look up a calendar by name and get a calendar object to use.
Indeed, we can even consult the map for a list of supported calendars,
to populate a UI's drop-down to select which to use.
Please suggest a better solution (and explain the problem with the
present solution), either here or in the review.
> The big problem is how you've implemented the new API in QDateTime and
> QLocale. There's code duplication that cannot be there in QLocale,
That's probably best addressed by you commenting on the review; I'm not
sure what duplication you're referring to ("cannot be there" is strong
language), although I do know about dateTimeToString(). There are a few
places I expect to find myself doing clean-up in the aftermath of
getting this all in, but I don't mind doing some of it before-hand.
Note, also, that this moves calendar-related data out of QLocale's
CLDR-derived data blob into calendar-specific data blobs - a step in the
general direction of making QLocale less monolithic.
> but the way you've removed the duplication in QDateTime also needs
> changing for performance reasons.
>
> int QDate::year() const
> {
> return year(QGregorianCalendar());
> }
>
> This creates a polymorphic object and makes a call that ends up delegating to
> it in
>
> if (cal.julianDayToDate(jd, y, m, d))
Please elaborate: why is this a problem ? The Gregorian arithmetic
naturally belongs in a calendar implementation. The date-time code
should naturally call it, rather than duplicating it in static functions
of its own (which have, naturally, been moved to become its methods).
> The commit also includes changes that look like unrelated clean-ups and will
> need to be split into different commits.
Please point these out on the review. Some of them might not be as
unrelated as you think - I did a fair bit of pulling separable changes
out already, rebasing Soroush's work onto the results. I may well have
missed some, but there were bits that couldn't be separated.
> It's at this point lacking documentation
Indeed, there remains work to be done. On the other hand, deciding what
shape the API should be is worth doing before taking pains over
documenting every detail - that would all change if we decide we need to
change the API.
> and there are a couple of coding style mistakes.
Please note in Gerrit.
Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Saturday, 5 August 2017 05:08:23 PDT Soroush Rabiei wrote:
> I believe our proposed change (containing locale backend , date and time
> classes and related widgets) is ready to be merged (maybe after some minor
> improvements)
>
> I would like to ask someone to review this change:
>
> https://codereview.qt-project.org/#/c/182341/
Ok, a quick review's quick conclusions:
I mostly like your API. It looks simple and well integrated into QDateTime and
QLocale. There are a couple of minor problems in the API itself, like
QCalendarWidget::calendar() returning a reference. That's just wrong and needs
work.
But there are bigger problems with the implementation, starting with
QAbstractCalendar having a static protected QMap member. The big problem is
how you've implemented the new API in QDateTime and QLocale. There's code
duplication that cannot be there in QLocale, but the way you've removed the
duplication in QDateTime also needs changing for performance reasons.
int QDate::year() const
{
return year(QGregorianCalendar());
}
This creates a polymorphic object and makes a call that ends up delegating to
it in
if (cal.julianDayToDate(jd, y, m, d))
The commit also includes changes that look like unrelated clean-ups and will
need to be split into different commits. It's at this point lacking
documentation and there are a couple of coding style mistakes.
In all, good work and I like how this is coming along, but it's not "ready for
beta" right now, so it shouldn't be included in dev until after 5.11 opens for
new features.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Saturday, 5 August 2017 05:08:23 PDT Soroush Rabiei wrote: > I believe our proposed change (containing locale backend , date and time > classes and related widgets) is ready to be merged (maybe after some minor > improvements) > > I would like to ask someone to review this change: > > https://codereview.qt-project.org/#/c/182341/ Will do, but it's a bit too late for the feature freeze in 3 days... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Calendar Systems proposal
I believe our proposed change (containing locale backend , date and time classes and related widgets) is ready to be merged (maybe after some minor improvements) I would like to ask someone to review this change: https://codereview.qt-project.org/#/c/182341/ Cheers, Soroush ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Monday 02 January 2017 09:21:25 Lars Knoll wrote: >>> I wonder whether we can't keep handling of different calendars >>> completely outside of QDate. Something similar to what we've done >>> with QString/QLocale. So QDate would continue unchanged and only >>> support the standard Gregorian calendar. In addition, we have a >>> QCalendar class, that can be constructed with a different calendar >>> system, and can then return 'localized' date strings, days, months >>> and years for this calendar system. >>> >>> Something like: >>> >>> QDate date; >>> QCalendar c(QCalendar::Hebrew); >>> QString hebrewDateString = c.toString(date); >>> int hebrewYear = c.year(date); >>> >>> Maybe one could even integrate this into QLocale, that already provides >>> support for localized month and day names? The current work actually moves QLocale's calendar-related data *out* to the calendar system classes - a step towards the dismembering of QLocle that was contemplated some years ago, but on which no progress appears to have been made. This separation is one of the particularly satisfying results of Soroush's work. Choice of calendar system is (kinda) orthogonal to choice of locale, anyway, so the calendar data doesn't belong in the QLocale (which only knows about language, script and country, although we *could* teach QLocale(const QString &) to parse more complications out of a string - I doubt that'd be a win). Note, by the way, that the locale data is the *only* data in most calendar system classes, handled as globals (as in QLocale) of the class's compilation unit. Calendar objects themselves are usually entirely algorithmic - they have no data members, just a vtable - although one can conceive of eccentric ones (that we aren't about to implement, but client code might) that could conceivably have member data (e.g. a historian might use a hybrid Julian/Gregorian calendar with one datum, the Julian day number at which to make the transition between the two; the class for that could be instantiated with different transition dates for the various jurisdictions that switched at different dates). On 02/01/17 12:01, "Frédéric Marchal" wrote: >> There is more to it than converting a date to a string: >> >> * Add N days to a date. >> * Find the number of days in a month. >> * Compare two dates. >> * Count the number of days between two dates. >> >> For instance a program wishing a happy new year to its users should >> do it with as little modifications as possible. >> >> Using a plain QDate would have been the easiest way to reach more >> users because it doesn't require to replace lots of QDate with a new, >> very similar, class. As it is not possible to change QDate for now, >> Soroush is looking for a temporary solution that would bridge the gap >> until Qt6 is out. Lars Knoll (2 January 2017 12:39) followed up with: > Sure, that there’s more to do than just the examples I listed. Still, > design wise it might be a good idea to have this functionality in a > class separate from QDate. We’ve done the same design decision for > QString (having no locale specific functionality in QString), and this > worked out rather nicely. So I would encourage you to have a look > whether and how a similar design could be done for calendar system > support. Actually, I do indeed want to move calendaring information - notably that of the Gregorian calendar - out of QDate; even though QDate must surely use Gregorian by default, moving the Gregorian logic (already largely separated into static functions) out makes the QDate class more straightforward. That actually leaves little in QDate itself; and what it does leave can readily be made calendar-system agnostic, although it manipulates a calendar-system object to do the work. So making Gregorian the default in APIs that take a calendar system is in fact a simplification of QDate, where I suppose locale-support complicated QString and its removal simplified. One big reason for wanting to integrate calendar into QDate is that, without it, the overhead of supporting alternate calendars in any app involves re-writing the app, reducing all use of QDate to a mere carrier for its ->toJulianDay(). With QDate taking a calendar object (that defaults Gregorian), it's fairly easy and painless to integrate calendar support into an app. This is rather well illustrated by Soroush's most recent patch-set (11), which extends QCalendarWidget to have QAbstractCalendar member (that, of course, shall default Gregorian), which it duly passes to each QDate method: https://codereview.qt-project.org#/c/182341/11/src/widgets/widgets/qcalendarwidget.cpp,unified This is easy, straightforward and natural; one can readily see that it's correct. (The one wrinkle, QCalendarModel::referenceDate(), being due to the existing comment looking suspiciously bogus, see my comments in Gerrit; search for "Oct 1582" on PS 11.) Now contrast this with what happens if we keep calendar systems out of QDate. There'
Re: [Development] Calendar Systems proposal
Edward Welbourne wrote: > (Coptic being also from Ethiopia) Uh, no. Coptic is from Egypt. According to Wikipedia, "Its years and months coincide with those of the Ethiopian calendar but have different numbers and names." Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
I had remarked: >> That shall complement Soroush Rabiei's work on the C++ side: Hamed Masafi (30 January 2017 21:07) replied: > Yes, that's right. I'm trying to port Soroush's calendar mechanism to > qml side of Qt. Good. >> If I understand Lars correctly, he prefers an API where the calendar >> object carries methods that act on a date and any further arguments >> it may need (similar to QLocale), so cal.toString(date, "-MM-dd") >> is more likely (although I personally like the style of API you give >> above, where the date object has the calendar-aware methods; too many >> of the details are the same between calendar systems). Aside from >> that, this is roughly the shape the C++ API shall have, making it a >> natural model for the QML to follow. > I'm not sure we can add an global type to script engine that are not > in ecma script. >From what I've now understood of ECMA-402, we can do much of this via the Date.toLocaleString() family of APIs, without non-ECMA types in our engine. It remains that we have a Qt object to which we can reasonably add things for use by QML - if we feel the need for it. >> Not sure what you're proposing here - you don't mention Qt.calendar >> in the code example, which looks more like 1) with JalaliCalendar >> moved to the Qt object - which may indeed be a better place for it >> than as a naked global object. > No; in this case Qt.JalaliCalendar is a QEnum and not an object (my > suggestion explained below) As explained elsewhere, I prefer an instance-based calendar system over an enum-based one *in C++*. However, from V4's perspective, that shall all be hidden inside QML's implementation and we'll most likely access it via names. An instance-based model can handle that by providing some way for the classes defining the instances we use in C++ to also tell the QML engine to associate them with a suitable name, e.g. 'Jalali', possibly with an alias mechanism - since Date.toLocaleString needs us to also recognise 'Persian' as referring to that. >> I don't know what rules QML might impose. Each of these would, in >> one way or another, require the calendar system code to register >> itself in some way with QML, associated with the name by which QML is >> to refer to it. The details of whether that name is in the namespace >> of some visible object (the ECMAScript global object or the Qt >> object) or in some internal mapping (for 2) are a matter of what's >> practical or convenient - someone with more QML fu than I can claim >> can advise you better there. > My prefer option is form (3) > We can add an enumeration to global space. > var date = new Date; > var out = date.toString(Qt.JalaliCalendar, "-MM-dd"); At the level of QML, this works fine; it's just another binding of a string to the underlying implementation of the calendar system. We shall need toLocale(|Date|Time)String(locale, options) to also know a binding to the u-ca-* fragments in locale. However, adapting the ECMA-262 Date.toString() to take such an enum would present compatibility problems; better to handle this within the ECMA-402 locale framework, as discussed earlier. > I think to continue we must conclusion on that calendar types must be > plugin or not? As discussed in my last mail, we don't need to actually do a plugin approach; the instance-based approach of Souroush's present work is just fine. Because third parties can sub-class QAbstractCalendar, they can do their own crazy things with plugins if they want, but we don't need to care about that. In QML, we can provide enum-like access to the calendar systems where we see a use for it; and we'll definitely need a string-based access in order to support date.toLocaleString() and its peers properly. Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Soroush Rabiei (30 January 2017 11:04) wrote:
> Speaking of the API, I wish to share an idea about not to put calendar
> implementations in a plugin subsystem.
I should clarify: when I spoke of calendar systems in plugins, I wasn't
suggesting we should do that as the normal mode for commonly-used
calendars. I prefer an instance-based system (over an enum-based one)
because it allows third parties to define a mechanism to support
calendar customisation, which might for example use a plugin. However,
the usual way of using the API would indeed be to instantiate a calendar
system provided either by Qt or by the application built on Qt.
> There are differences between those concepts that are implemented as
> plugins and calendars. A calendar system is not an image format nor a
> database implementation.
It is, however, something that each user typically only wants one or a
few of, despite there being many more for which they have no use. That,
to me, is the decisive place where a plugin architecture is a win; spare
users the bloat of the ones they don't need, while supporting those most
users do need and making it easy to have others as needed.
> There will be no new calendar (at least, it's unlikely to have a brand
> new calendar) and there will be no newer versions of existing
> calendars. What is the point of having calendars as plugins?
There are, however, existing calendars with more variations than we
shall be happy to support: for example, the Islamic calendar, when
implemented strictly by astronomic observation, has a different variant
for each location, albeit with only minor variations. We can *allow*
for those who want (for whatever reason) to follow this for their
location, without having to actually support them ourselves. They can
subclass our Islamic calendar class (which shall provide the relevant
locale-specific details and generic structure), apply their tweaks and
have the calendar they want.
This does also mean that we can initially support a small sub-set of
calendar systems and wait for contributors to supply the rest, rather
than feeling obliged to implement a dozen or more different calendar
systems ourselves at the outset - for each of which we'd need to do
significant research (and we'd probably get some of them wrong).
> And we have to keep QGregorianCalendar everywhere after
> all... And we will have the problem of instantiation. While plugins
> have no public header, then how we are supposed to use them in code?
> Like this:
>
> QDate d;
> d.setDate(y,m,d,QCalendar::fromName("jalali"));
>
> Or maybe:
>
> d.setDate(y,m,d,"jalali");
>
> Let's add all calendar systems that do have locale information in
> CLDR,
That's probably more work than we want to do - how familiar are you with
the algorithms for computation of the different calendar systems ? I'm
sure we can look each up on Wikipedia - and *most* of them shall have
sufficiently well-established algorithms for mapping to and from Julian
day number that we can implement them; but, even so, it's going to take
a pile of work to do that; and lack of someone familiar with a calendar
is apt to leave us innocently making embarrassing mistakes. Better to
make it easy for others to contribute the ones they care about, while
we implement the ones we know.
> and make all of them configurable as to be built or not, except
> QGregorianCalendar. Then decide on a default subset of calendars to be
> compiled into qtbase. That will be something like:
>
> ++-++++
> |No. |Name |Variant |Configurable|Default |
> ++-++++
> |1 |Gregorian||No |Yes |
> ++-++++
> |2 |Islamic |Astronomical|Yes |No |
> ++-++++
> |3 |Islamic |Civil (Algorithmic) |Yes |Yes |
> ++-++++
> |4 |Persian ||Yes |Yes |
> ++-++++
> |5 |Hebrew ||Yes |Yes |
> ++-++++
> |6 |Chinese ||Yes |Yes |
> ++-++++
> |7 |Japanese ||Yes |No |
> ++-++++
> |8 |Buddhist ||Yes |No |
> ++-++++
> |9 |Republic of China||Yes |No |
> ++-++++
> |10 |Coptic
Re: [Development] Calendar Systems proposal
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, "-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, '-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.
_
Re: [Development] Calendar Systems proposal
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, "-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:
> >
> 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. 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
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.
> 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 Burchell
ro...@crimson.no
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
> That shall complement Soroush Rabiei's work on the C++ side:
Yes, that's right. I'm trying to port Soroush's calendar mechanism to qml
side of Qt.
> If I understand Lars correctly, he prefers an API where the calendar
> object carries methods that act on a date and any further arguments it
> may need (similar to QLocale), so cal.toString(date, "-MM-dd") is
> more likely (although I personally like the style of API you give above,
> where the date object has the calendar-aware methods; too many of the
> details are the same between calendar systems). Aside from that, this
> is roughly the shape the C++ API shall have, making it a natural model
> for the QML to follow.
I'm not sure we can add an global type to script engine that are not in
ecma script.
> Not sure what you're proposing here - you don't mention Qt.calendar in
> the code example, which looks more like 1) with JalaliCalendar moved to
> the Qt object - which may indeed be a better place for it than as a
> naked global object.
No; in this case Qt.JalaliCalendar is a QEnum and not an object (my
suggestion explained below)
> I don't know what rules QML might impose. Each of these would, in one
> way or another, require the calendar system code to register itself in
> some way with QML, associated with the name by which QML is to refer to
> it. The details of whether that name is in the namespace of some
> visible object (the ECMAScript global object or the Qt object) or in
> some internal mapping (for 2) are a matter of what's practical or
> convenient - someone with more QML fu than I can claim can advise you
> better there.
My prefer option is form (3)
We can add an enumeration to global space.
var date = new Date;
var out = date.toString(Qt.JalaliCalendar, "-MM-dd");
> 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. 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);
But there are some bugs related to this prototype, We have to solve that
within this process.
https://bugreports.qt.io/browse/QTBUG-32492
https://bugreports.qt.io/browse/QTBUG-41712
> var out = date.toString("/MM/dd", Qt.JalaliCalendar); // Is
> this possible?
This is my choice too. And answer is "yes". This is possible. But for that
we must conclusion below paragraph [*]:
> There are differences between those concepts that are implemented as
> plugins and calendars. A calendar system is not an image format nor a
> database implementation. There will be no new calendar (at least, it's
> unlikely to have a brand new calendar) and there will be no newer
> versions of existing calendars. What is the point of having calendars
> as plugins? And we have to keep QGregorianCalendar everywhere after
> all... And we will have the problem of instantiation. While plugins
> have no public header, then how we are supposed to use them in code?
> Like this:
[*]: I'm agree with Soroush. Calendar system must bot be pluginable. Due
the facts that soroush said.
I think to continue we must conclusion on that calendar types must be
plugin or not?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On segunda-feira, 30 de janeiro de 2017 15:43:30 PST Soroush Rabiei wrote: > Can we have calendars for 5.9 ? It's not FF yet I suppose. And there's > not much to do. Either we implement calendars as factory classes > operating on QDate, or adding to QDate's API, there is not much work > left to do. I'll review your change proposal to QDate, but don't hold your hopes up that it'll pass in time for the feature freeze. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Can we have calendars for 5.9 ? It's not FF yet I suppose. And there's not much to do. Either we implement calendars as factory classes operating on QDate, or adding to QDate's API, there is not much work left to do. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Mon, Jan 30, 2017, at 08:59 AM, Hamed Masafi wrote: > I'm working on qml support of calendar system, > for porting this mechanism to qml we have two option: 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 Disclaimer: I'm not intimately familiar with this API, but stumbled across it while looking into other possible alternatives for this problem. -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
> Now question is that: witch form is preferred? Will be case (1) break Qt
> rules?
I don't know about QML and it'd design principles, but I like option
3. Though it must take that calendar instance as second argument I
suppose:
var out = date.toString("/MM/dd", Qt.JalaliCalendar); // Is
this possible?
Speaking of the API, I wish to share an idea about not to put calendar
implementations in a plugin subsystem.
There are differences between those concepts that are implemented as
plugins and calendars. A calendar system is not an image format nor a
database implementation. There will be no new calendar (at least, it's
unlikely to have a brand new calendar) and there will be no newer
versions of existing calendars. What is the point of having calendars
as plugins? And we have to keep QGregorianCalendar everywhere after
all... And we will have the problem of instantiation. While plugins
have no public header, then how we are supposed to use them in code?
Like this:
QDate d;
d.setDate(y,m,d,QCalendar::fromName("jalali"));
Or maybe:
d.setDate(y,m,d,"jalali");
Let's add all calendar systems that do have locale information in
CLDR, and make all of them configurable as to be built or not, except
QGregorianCalendar. Then decide on a default subset of calendars to be
compiled into qtbase. That will be something like:
++-++++
|No. |Name |Variant |Configurable|Default |
++-++++
|1 |Gregorian||No |Yes |
++-++++
|2 |Islamic |Astronomical|Yes |No |
++-++++
|3 |Islamic |Civil (Algorithmic) |Yes |Yes |
++-++++
|4 |Persian ||Yes |Yes |
++-++++
|5 |Hebrew ||Yes |Yes |
++-++++
|6 |Chinese ||Yes |Yes |
++-++++
|7 |Japanese ||Yes |No |
++-++++
|8 |Buddhist ||Yes |No |
++-++++
|9 |Republic of China||Yes |No |
++-++++
|10 |Coptic ||Yes |No |
++-++++
|11 |Ethiopic |Amete Alem |Yes |No |
++-++++
|12 |Ethiopic |Amete Mihret|Yes |No |
++-++++
|13 |Indian ||Yes |No |
++-++++
For historical calendars, Qt users are unlikely to add marginal
calendar systems -> A reason to avoid plugin system. Though having
current schema, they can subclass QAbstractCalendar and add their
calendar (not as a loadable plugin) in their own code.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Hamed Masafi (30 January 2017 08:59):
> I'm working on qml support of calendar system,
That shall complement Soroush Rabiei's work on the C++ side:
https://codereview.qt-project.org/182341
http://bugreports.qt.io/browse/QTBUG-58404
Prior discussion:
http://lists.qt-project.org/pipermail/development/2016-December/028125.html
http://lists.qt-project.org/pipermail/development/2017-January/028234.html
> for porting this mechanism to qml we have two option:
>
> 1)
> Add a global object to jsengine?
> Somthing like that :
>
> var date = new Date;
> var cal = new JalaliCalendar;
> var out = date.toString(cal, "-MM-dd");
>
> In this case JalaliCalendar is a new global object type (like date,
> string, regex, array and etc).
If I understand Lars correctly, he prefers an API where the calendar
object carries methods that act on a date and any further arguments it
may need (similar to QLocale), so cal.toString(date, "-MM-dd") is
more likely (although I personally like the style of API you give above,
where the date object has the calendar-aware methods; too many of the
details are the same between calendar systems). Aside from that, this
is roughly the shape the C++ API shall have, making it a natural model
for the QML to follow.
That C++ API is designed, however, with an eye on the long tail of less
widely used calendars - we aim to let their users be able to add a C++
class, possibly via a plugin, whose instances implement their calendar.
With this model for QML's API, that would require them to *also* add a
QML aspect of their C++ class. I'm not sure how easy that is, or how
pluggable.
> 2)
> Or another option may be adding calendar() to global Qt function, the
> usage example can be like that:
>
> var date = new Date;
> var out = date.toString(Qt.calendar('jalali'), "-MM-dd");
This would require some infrastructure behind Qt.calendar() that would
let authors of calendar system classes register them so that it knows
how to instantiate them. If that's easier than whatever it takes to add
a global object to QML (or an property of the Qt object), it might be a
good way to make life easier for calendar system implementors.
> 3)
>
> var date = new Date;
> var out = date.toString(Qt.JalaliCalendar, "-MM-dd");
>
> In this method Qt.calendar like Qt.locale initialize with a string.
Not sure what you're proposing here - you don't mention Qt.calendar in
the code example, which looks more like 1) with JalaliCalendar moved to
the Qt object - which may indeed be a better place for it than as a
naked global object.
> Now question is that: witch form is preferred? Will be case (1) break
> Qt rules?
I don't know what rules QML might impose. Each of these would, in one
way or another, require the calendar system code to register itself in
some way with QML, associated with the name by which QML is to refer to
it. The details of whether that name is in the namespace of some
visible object (the ECMAScript global object or the Qt object) or in
some internal mapping (for 2) are a matter of what's practical or
convenient - someone with more QML fu than I can claim can advise you
better there.
Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Calendar Systems proposal
I'm working on qml support of calendar system,
for porting this mechanism to qml we have two option:
1)
Add a global object to jsengine?
Somthing like that :
var date = new Date;
var cal = new JalaliCalendar;
var out = date.toString(cal, "-MM-dd");
In this case JalaliCalendar is a new global object type (like date, string,
regex, array and etc).
2)
Or another option may be adding calendar() to global Qt function, the usage
example can be like that:
var date = new Date;
var out = date.toString(Qt.calendar('jalali'), "-MM-dd");
3)
var date = new Date;
var out = date.toString(Qt.JalaliCalendar, "-MM-dd");
In this method Qt.calendar like Qt.locale initialize with a string.
Now question is that: witch form is preferred? Will be case (1) break Qt
rules?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Em terça-feira, 17 de janeiro de 2017, às 10:22:57 PST, Edward Welbourne escreveu: > Jake Petroules > > > Eddy, "draft" does not do what you think it does. This is why no one can > > see the change. > I think you are addressing the wrong person. > Soroush created the review (as a draft) and added me as a reviewer. > That enabled me to add Frederic. > > > Please remove "draft" status and add "WIP: " at the front of the commit > > message instead so we can all take a look. > It already has WIP: on its commit message. > > Soroush: please push your next patch set to refs/for/dev, to make the review > public. Subsequent pushes can be to refs/drafts/dev if you like, to make > clear it's all still a draft. People not added to the reviews will not see them. Don't use refs/drafts for anything you want other people to see. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Allan Sandfeld Jensen asked: > Are you aware of KCalenderSystem? Yes - Sergio Martins helpfully brought it up a couple of weeks ago: http://lists.qt-project.org/pipermail/development/2017-January/028241.html Current plan is roughly to upstream it. Debate remains as to whether it should sit outside QDate (Lars) or be taken by overloads of QDate methods to tweak their action (Soroush and I). Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Jake Petroules > Eddy, "draft" does not do what you think it does. This is why no one can see > the change. I think you are addressing the wrong person. Soroush created the review (as a draft) and added me as a reviewer. That enabled me to add Frederic. > Please remove "draft" status and add "WIP: " at the front of the commit > message instead so we can all take a look. It already has WIP: on its commit message. Soroush: please push your next patch set to refs/for/dev, to make the review public. Subsequent pushes can be to refs/drafts/dev if you like, to make clear it's all still a draft. Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Thursday 15 December 2016, Soroush Rabiei wrote: > Currently there is no support of any calendar system other than Gregorian. > Gregorian calendar is widely used in western countries. However most > countries > in Middle-east, Asia and Africa use other calendar systems. Unfortunately > there > is no support for them. > Are you aware of KCalenderSystem? It appears to have most of the calenders, and is under LGPL, not sure if it has been ported to KDE Frameworks though, and it could probably be useful to reimplement for Qt inclusion, but it might be worth checking out if you plan to implement something similar. Best regards `Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Eddy, "draft" does not do what you think it does. This is why no one can see the change. Please remove "draft" status and add "WIP: " at the front of the commit message instead so we can all take a look. Thanks, > On Jan 16, 2017, at 5:07 AM, Edward Welbourne wrote: > > On Sunday 15 January 2017 14:39:49 Soroush Rabiei wrote: >>> Just submitted first change set: >>> >>> https://codereview.qt-project.org/#/c/182341/ > > Frédéric Marchal replied: >> I'm seeing an error: "The page you requested was not found, or you do >> not have permission to view this page." > > I've just added you to the list of reviewers - does that help ? > > Eddy. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Sunday 15 January 2017 14:39:49 Soroush Rabiei wrote: >> Just submitted first change set: >> >> https://codereview.qt-project.org/#/c/182341/ Frédéric Marchal replied: > I'm seeing an error: "The page you requested was not found, or you do > not have permission to view this page." I've just added you to the list of reviewers - does that help ? Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Sunday 15 January 2017 14:39:49 Soroush Rabiei wrote: > Just submitted first change set: > > https://codereview.qt-project.org/#/c/182341/ I'm seeing an error: "The page you requested was not found, or you do not have permission to view this page." Frederic ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Just submitted first change set: https://codereview.qt-project.org/#/c/182341/ Planning to add three more calendars and separate index array (to reduce overhead on locales) this week. Persian calendar is still one day behind. Seems to be related to julian day base. The original algorithm counts day 1 as a base date. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Le 13/01/2017 à 15:46, Edward Welbourne a écrit : Soroush Rabiei 1. All calendaring systems, show dates in three levels: Year, Month and Day 2. The week is 7 days. It may start at any of these days. French revolutionary calendar: https://en.wikipedia.org/wiki/French_Republican_Calendar Not that I propose supporting it ! Don't forget that in addition to weeks being 10 days, days are also divided into 10 decimal hours, each of them counting 100 decimal minutes. It would be a lot of fun to support it. But not sure anyone actually needs that. ;-) -- Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Edward Welbourne wrote: > Soroush Rabiei >> 3. Number of months in all years are fixed. > > Is there no lunar calendar with occasional extra months ? Of course there is. Any lunar calendar adjusted for consistency with the solar year necessarily has occasional intercalar months. The Jewish calendar is the most prominent example. (The Islamic calendar, on the other hand, is the most prominent example of a lunar calendar that is NOT adjusted for the solar year, which explains why e.g. Ramadan rotates all over the solar year over the years.) Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Soroush Rabiei > Sorry for being noisy on this list, but I think we have several issues > needed discussion before going further. I should note that Lars still holds to the view that we should keep this out of QDate: which seems to imply roughly just upstreaming KCalendarSystem, albeit with the opportunity to make any improvements we want in the process. > First we have a design decision to make, the minimal set of > assumptions on calendaring systems. According to my minute research we > can assume following facts on every calendar that is in-use: > > 1. All calendaring systems, show dates in three levels: Year, Month and Day > 2. The week is 7 days. It may start at any of these days. French revolutionary calendar: https://en.wikipedia.org/wiki/French_Republican_Calendar Not that I propose supporting it ! However, it would be best to design a system which doesn't preclude someone else implementing it. If we can avoid hard-coding the assumption of a seven-day week, so much the better. > 3. Number of months in all years are fixed. Is there no lunar calendar with occasional extra months ? > Please let me know about any problem. > > Second issue is on CLDR data. I was all mistaken about CLDR. The new > versions (including v29) include month name data for many calendars > (Gregorian, Buddhist, Chinese, Coptic, Dangi, Ethiopic, Hebrew, > Indian, Islamic, Japanese and Persian). I managed to modify the > scripts (cldr2qlocalexml.py and qlocalexml2cpp.py) to prepare data for > Jalali calendar (named as Persian in CLDR terminology). On the other > hand, QLocale integration is completed. Now there is `months_data_per' > array in qlocale_data_p.h and it's working well. > > The problem however, is that this data is bigger than what I had in > mind. Apparently there are many communities using Jalali calendars. > There are strange month names for Korean, Russian, Turkish and several > more. (I was expecting data only for Persian and Afghani languages, > maybe Tajik too...) The array containing month names is 2419 bytes. > There is also another 6*2=12 bytes per locale in locale's index table. > considering number of supported locales in qt, we will have 552 * 12 = > 6624 bytes there and as a result the overhead in Qt's binary, will be > 9.043 KB only for Jalali calendar. Islamic civil calendar is almost > three times bigger if I'm not much mistaken, and I have no idea about > other calendars. I guess adding five calendars will blow QtCore up to > 5~7 Megabytes. Not something we want to impose on all users of Qt. > I have changed qlocalexml2cpp.py such that it generates data for each > calendar in a separate array. So it can be excluded by preprocessor > directives. My suggestion is to make calendaring support, > configurable, and provide data only for Gregorian calendar by default. > And also we can give users the option to choose among locales they > want to include in their builds: > > ./configure -developer-build -opensource -confirm-license -debug > -calendars gregorian,persian,islamic_civil That sounds reasonable. Another approach might be to design a plugin-based architecture - with similar config, but controlling which plugins get built. This would make life easier for anyone who wants to add a calendar system we don't support: they'd just need to add their plugin to wherever we put ours. Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Sorry for being noisy on this list, but I think we have several issues needed discussion before going further. First we have a design decision to make, the minimal set of assumptions on calendaring systems. According to my minute research we can assume following facts on every calendar that is in-use: 1. All calendaring systems, show dates in three levels: Year, Month and Day 2. The week is 7 days. It may start at any of these days. 3. Number of months in all years are fixed. Please let me know about any problem. Second issue is on CLDR data. I was all mistaken about CLDR. The new versions (including v29) include month name data for many calendars (Gregorian, Buddhist, Chinese, Coptic, Dangi, Ethiopic, Hebrew, Indian, Islamic, Japanese and Persian). I managed to modify the scripts (cldr2qlocalexml.py and qlocalexml2cpp.py) to prepare data for Jalali calendar (named as Persian in CLDR terminology). On the other hand, QLocale integration is completed. Now there is `months_data_per' array in qlocale_data_p.h and it's working well. The problem however, is that this data is bigger than what I had in mind. Apparently there are many communities using Jalali calendars. There are strange month names for Korean, Russian, Turkish and several more. (I was expecting data only for Persian and Afghani languages, maybe Tajik too...) The array containing month names is 2419 bytes. There is also another 6*2=12 bytes per locale in locale's index table. considering number of supported locales in qt, we will have 552 * 12 = 6624 bytes there and as a result the overhead in Qt's binary, will be 9.043 KB only for Jalali calendar. Islamic civil calendar is almost three times bigger if I'm not much mistaken, and I have no idea about other calendars. I guess adding five calendars will blow QtCore up to 5~7 Megabytes. I have changed qlocalexml2cpp.py such that it generates data for each calendar in a separate array. So it can be excluded by preprocessor directives. My suggestion is to make calendaring support, configurable, and provide data only for Gregorian calendar by default. And also we can give users the option to choose among locales they want to include in their builds: ./configure -developer-build -opensource -confirm-license -debug -calendars gregorian,persian,islamic_civil Cheers, Soroush ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
I observed:
>> Issue: Q(Date|Time)+ think day-changes happen at midnight. [...] Has
>> secular society shifted the day boundary to midnight in practice ?
Soroush replied:
> Indeed they do the simplification needed to adopt modern lifestyle.
OK, good - then we have an excuse to keep the simple model !
> As far as I know, modern lunar calendars being used in ME as official
> calendars, have loads of simplifications applied compared to the
> original calendars. The start of a month in Islamic calendar in Fiqh
> (regional calendar) is based on observing new moon (by unaided eye) in
> the sky. That's why Saudi Arabia sometimes celebrate end of Ramadan
> one day after Turkey, and one day before Iran. That's why number of
> days differ from a year to another.
All of which argues for us to support the simplified official version,
while making it possible for apps and user-communities to add in their
own implementations taking account of local quirks.
> Though, the start of the day is 00:00 in modern calendars. And number
> of days in months are fixed.
That, at least, is reassuring ;-)
> Anyway, the only country using lunar calendar (Saudi Arabia) just
> switched to solar system (Gregorian). But we have to support Islamic
> calendar (modern version) of course.
Indeed - even if it's not the official state calendar, there are folk
still using it who shall want their software to respect that. We can
make that *possible*, even where we aren't going to do all of the
work ourselves ...
> My current implementation looks like KCalendarSystem with some
> differences. Calendar classes are subclassed from QAbstractCalendar,
> and have to implement several methods. I tried to make this class as
> generic as possible, there is no assumption on month days and number
> of months.
Sounds promising. If you can push it to gerrit as a work in progress
(start the subject line of the commit message with "WIP: " and the
system shall know what you mean; you can also push to refs/drafts/dev to
make it a draft review, until you eventually push to refs/for/dev to
turn it into a "real" review), I'll take a look at it and we can discuss
more there (taking traffic off this list).
I was tidying up in our Wiki after wearing out my brain on Friday and
stumbled upon [0], a 2011 write-up of relevant ideas - written by John
Layt, who is the author of KCalendarSystem. (Speaking of: if anyone is
in touch with him and can reach him other than via his @KDE e-mail,
which I've pinged, please do bring this discussion to his attention.)
It may be a source of some fruitful insights.
[0] https://wiki.qt.io/Qt-contributors-summit-2011-QDateTime
> I just finished adding new methods to QDate and it's working for
> Jalali Calendar.
>
> QDate d = QDate::currentDate();
> int gyear1 = d.year(); // 2017
> int gyear2 = d.year(QGregorianCalendar); // 2017
> int jyear1 = d.year(QJalaliCalendar()); // 1395
> int jyear2 = d.year(QAbstractCalendar::fromName("jalali")); // 1395
Nice. I interpolate a missing () on the end of QGregorianCalendar().
> I didn't touch Gregorian calculations in QDate, just added more
> functions. Does removing static members count as an ABI change? I'm
> planning to move all the math out of QDate into QGregorianCalendar.
A static function is invisible to anything outside its own compilation
unit, so turning assorted static functions in qdatetime.cpp into methods
of QGregorianCalendar is entirely feasible. You can even mess with
QDateTimePrivate - see the warning comment in qdatetime_p.h ;^>
Static members of a public class, however, have to stay (I suppose).
Not that you have to continue *using* them, if something else makes them
redundant ...
> About calendaring widgets, The widget obviously needs to keep
> information on what calendar system it uses. I think it's possible to
> add members to private API classes? After all it's **private** and
> there's only a pointer to private API class in main class. So it would
> be A[BP]I compatible I suppose.
Check for that warning comment, or a header-name ending _p.h - you can
get away with plenty of change there.
> And also we need to add some functions to main class:
>
> void QDateEdit::setCalendar(QAbstractCalendar* cal); // maybe a QString?
> QAbstractCalendar* QDateEdit::calendar() const; // meh...
Those make sense. Definitely pass QAbstractCalendar * to the setter;
otherwise, client code can't supply a custom calendar that's not known
to our abstract base class's method. The advantage of an overload
taking QString is minor - it'll package a call to fromName - and I fear
it would add confusions, with folk expecting too much of it, or a
matching getter returning QString.
Please keep QDateEdit changes in a separate commit from QDateTime
changes; ideally, even separate the creation of QCalendarSystem's base
class (at least) from re-working QDateTime to break out
QGregorianCalendar.
> There is another issue: How do we add calendar localization to QLocale?
I don't
Re: [Development] Calendar Systems proposal
Greetings all, and happy new year
> Issue: Q(Date|Time)+ think day-changes happen at midnight. Some
>
calendar systems think they happen at sunset or sunrise; these are both
> rather tricky, as their time depends on date and latitude [3] - and I'm
> not sure what they do about days when the sun doesn't set or rise at
> all. I don't see any hint of coping with this in KCalendarSystem and
> I'm fairly sure I don't want to solve that problem, so I think we stick
> with midnight and leave apps using the result to fix up after the fact
> if they really care. Indeed, what *is* common practice in The Middle
> East, as regards how evenings get handled - as the tail of one day or
> the start of the next ? Has secular society shifted the day boundary to
> midnight in practice ?
>
Indeed they do the simplification needed to adopt modern lifestyle. As far
as I know, modern lunar calendars being used in ME as official calendars,
have loads of simplifications applied compared to the original calendars.
The start of a month in Islamic calendar in Fiqh (regional calendar) is
based on observing new moon (by unaided eye) in the sky. That's why Saudi
Arabia sometimes celebrate end of Ramadan one day after Turkey, and one day
before Iran. That's why number of days differ from a year to another.
Though, the start of the day is 00:00 in modern calendars. And number of
days in months are fixed.
Anyway, the only country using lunar calendar (Saudi Arabia) just switched
to solar system (Gregorian). But we have to support Islamic calendar
(modern version) of course.
My current implementation looks like KCalendarSystem with some differences.
Calendar classes are subclassed from QAbstractCalendar, and have to
implement several methods. I tried to make this class as generic as
possible, there is no assumption on month days and number of months. I just
finished adding new methods to QDate and it's working for Jalali Calendar.
QDate d = QDate::currentDate();
int gyear1 = d.year(); // 2017
int gyear2 = d.year(QGregorianCalendar); // 2017
int jyear1 = d.year(QJalaliCalendar()); // 1395
int jyear2 = d.year(QAbstractCalendar::fromName("jalali")); // 1395
I didn't touch Gregorian calculations in QDate, just added more functions.
Does removing static members count as an ABI change? I'm planning to move
all the math out of QDate into QGregorianCalendar.
About calendaring widgets, The widget obviously needs to keep information
on what calendar system it uses. I think it's possible to add members to
private API classes? After all it's **private** and there's only a pointer
to private API class in main class. So it would be A[BP]I compatible I
suppose. And also we need to add some functions to main class:
void QDateEdit::setCalendar(QAbstractCalendar* cal); // maybe a QString?
QAbstractCalendar* QDateEdit::calendar() const; // meh...
There is another issue: How do we add calendar localization to QLocale?
Cheers,
Soroush
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On 05.01.2017 17:12, Edward Welbourne wrote: Sérgio Martins very helpfully linked to KCalendarSystem - thank you. One of the things we should clearly aim for is to make it easy for KCalendarSystem to (when its developers care to and can find the time, with no pressure to do so) adapt to use QCalendarSystem and the adapted QDate. TODO: I also need to find and talk to its maintainers. Maintainer for KCalenderSystem was John Layt. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Well, I've missed a long and lively discussion while I was away. I've
now caught up with e-mail, digested the thread and done some (but by no
means enough) background reading; that's left me with some jumbled
notes. This shall be long - let's start with the thread (and fit some
of those notes into answering it):
Soroush Rabiei:
>>> Please tell me more about your idea when you're back.
Take KCalendarSystem [0], replace its uses of QDate with a Julian day
number (as int [1]), tidy up a bit and have relevant Q(Date|Time)+
methods take one of these as an optional parameter (default: Gregorian)
that configures what they mean by things like year, month, week and day
within any of these.
[0]
https://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKCalendarSystem.html
[1] I notice that QDate uses a qint64 for Julian day, which is overkill;
a 32-bit integral type lets us have 5,879,610 years each side of our
epoch, which is ample, IMO. KCalendarSystem seems to agree. QDate
can't change that for its data member, nor do I propose to change its
method signatures, but I see no reason for the calendar system to use
anything bigger than int for Julian dates.
Of course, BC/SC reasons mean "optional parameter" won't (until maybe Qt
6) be an added parameter (with a default) at the ends of existing
methods but a (probably first and non-optional) parameter of overloads
of the existing methods. Or something like that.
>>> I suppose adding new calendars by users, requires
>>> subclassing QDate?
A user calendar would be implemented by sub-classing the calendar system
virtual base class. Instances of that would be passed to methods of
(stock) QDate to over-ride its default use of Gregorian.
>>> Or maybe somehow extend the enum that contains calendar
>>> systems[?].
An enum can only support the calendar systems for which Qt contains
code. There shall always be calendars we don't support: it would be
best to ensure users can get support for that, one way or another. An
app-developer with enough users who want a particular calendar system
should be able to add support for it without waiting for us to care
about that calendar system.
>>> I think adding the information on which calendar system is
>>> current date is on, can be added as a member (handlre/enum)
>>> to QDate.
{Backwards,Source} Compatibility (BC/SC, above) issues preclude that.
Sune Vuorela:
>> I think you need to touch quite some of the 'inner bits' of
>> date / time
That's fine - messing with internals is OK, it's public A[BP]Is that
can't be changed - except by adding methods. Most of what I envisage us
changing for this would be turning some existing static functions in the
code into methods of a QGregorianCalendarSystem class, that implements
a generic QCalendarSystem API.
>> my two missing pet features:
>> - Partial dates
I'm quite sure these don't belong in Q(Date|Time)+, for all that I can
see their value in calendar (and similar) apps. There might be a case
for a recurrent event class, that supports all the funky things for
repeating calendar entries - e.g. the first Sunday following a full Moon
which falls on or after the Spring equinox, optionally with "full moon"
and/or "equinox" defined by some arbitrary set of rules rather than by
actual astronomical reality [2] - which would surely include partial
dates. I encourage you to think about designing that and would be happy
to review any contribution that results ;^>
[2] https://en.wikipedia.org/wiki/Computus
I did not just make that up.
>> - Date/time intervals/delta's.
Those I can see a better case for: they could be handled by operator-()
methods (with returns measured in the given units) of QDate (days),
QTime (milliseconds), QDateTime (milliseconds, 64-bit). No operator+;
use addDays(), addSeconds(), &c.
>> (by date/time deltas, I e.g. I started working somewhere on
>> november 1st 2014. and stopped january 3rd 2015. How long did
>> I work there)
Quite. Note, however, that KCalendarSystem::dateDifference() raises a
valid point for broken-down difference in days, months, years - which
need not equate to a simple number of days. [2016-03-01] - [2016-02-01]
is 29 days but the dateDifference is 1 month; while the same in 2017 is
28 days but still 1 month; and [2017-02-01] - [2016-02-01] is one year,
the same as [2017-05-01] - [2016-05-01], but the former is 366 days and
the latter is 365 days. Other calendar systems shall doubtless give
more such subtleties.
André Somers
> If memory serves me right: When, years ago, I tried to get the
> latter in, the work was a bit blocked because somebody else
> what working on... calendar support. :-)
If you can find either your patches for diff or their patches for
calendar support, I'm sure they'd be useful input to the present effort.
Ch'Gans (a.k.a. Chris):
Boost have
Re: [Development] Calendar Systems proposal
On segunda-feira, 2 de janeiro de 2017 12:01:49 BRST Frédéric Marchal wrote: > There is more to it than converting a date to a string: > > * Add N days to a date. > * Find the number of days in a month. > * Compare two dates. > * Count the number of days between two dates. All but the second one are possible already with QDate, since they don't depend on the calendaring system in use. > For instance a program wishing a happy new year to its users should do it > with as little modifications as possible. > > Using a plain QDate would have been the easiest way to reach more users > because it doesn't require to replace lots of QDate with a new, very > similar, class. As it is not possible to change QDate for now, Soroush is > looking for a temporary solution that would bridge the gap until Qt6 is > out. I don't think I'll ever allow making those deep changes to QDate. Just like QString being able to format numbers in one particular locale (the "C" locale), we ought to support the C locale's calendaring system in QDate too. If nothing else, because people are using that code right now and have been for 20 years. > BTW, happy new year to those using the Gregorian calendar :-) Happy Gregorian New Year. 15 days until the Julian New Year. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On 2017-01-02 11:01, Frédéric Marchal wrote: (...) There is more to it than converting a date to a string: * Add N days to a date. * Find the number of days in a month. * Compare two dates. * Count the number of days between two dates. Hi, Have you seen KCalendarSystem ? https://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKCalendarSystem.html It can do all the above and doesn't require disruptive changes such as modifying QDate. It's also stable and well tested, as it's been used in Kontact for many years. Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Sure, that there’s more to do than just the examples I listed. Still, design wise it might be a good idea to have this functionality in a class separate from QDate. We’ve done the same design decision for QString (having no locale specific functionality in QString), and this worked out rather nicely. So I would encourage you to have a look whether and how a similar design could be done for calendar system support. Cheers, Lars On 02/01/17 12:01, "Frédéric Marchal" wrote: On Monday 02 January 2017 09:21:25 Lars Knoll wrote: > I wonder whether we can't keep handling of different calendars completely > outside of QDate. Something similar to what we've done with > QString/QLocale. So QDate would continue unchanged and only support the > standard Gregorian calendar. In addition, we have a QCalendar class, that > can be constructed with a different calendar system, and can then return > 'localized' date strings, days, months and years for this calendar system. > > Something like: > > QDate date; > QCalendar c(QCalendar::Hebrew); > QString hebrewDateString = c.toString(date); > int hebrewYear = c.year(date); > > Maybe one could even integrate this into QLocale, that already provides > support for localized month and day names? There is more to it than converting a date to a string: * Add N days to a date. * Find the number of days in a month. * Compare two dates. * Count the number of days between two dates. For instance a program wishing a happy new year to its users should do it with as little modifications as possible. Using a plain QDate would have been the easiest way to reach more users because it doesn't require to replace lots of QDate with a new, very similar, class. As it is not possible to change QDate for now, Soroush is looking for a temporary solution that would bridge the gap until Qt6 is out. BTW, happy new year to those using the Gregorian calendar :-) Frederic ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Monday 02 January 2017 09:21:25 Lars Knoll wrote: > I wonder whether we can't keep handling of different calendars completely > outside of QDate. Something similar to what we've done with > QString/QLocale. So QDate would continue unchanged and only support the > standard Gregorian calendar. In addition, we have a QCalendar class, that > can be constructed with a different calendar system, and can then return > 'localized' date strings, days, months and years for this calendar system. > > Something like: > > QDate date; > QCalendar c(QCalendar::Hebrew); > QString hebrewDateString = c.toString(date); > int hebrewYear = c.year(date); > > Maybe one could even integrate this into QLocale, that already provides > support for localized month and day names? There is more to it than converting a date to a string: * Add N days to a date. * Find the number of days in a month. * Compare two dates. * Count the number of days between two dates. For instance a program wishing a happy new year to its users should do it with as little modifications as possible. Using a plain QDate would have been the easiest way to reach more users because it doesn't require to replace lots of QDate with a new, very similar, class. As it is not possible to change QDate for now, Soroush is looking for a temporary solution that would bridge the gap until Qt6 is out. BTW, happy new year to those using the Gregorian calendar :-) Frederic ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
I wonder whether we can't keep handling of different calendars completely outside of QDate. Something similar to what we've done with QString/QLocale. So QDate would continue unchanged and only support the standard Gregorian calendar. In addition, we have a QCalendar class, that can be constructed with a different calendar system, and can then return 'localized' date strings, days, months and years for this calendar system. Something like: QDate date; QCalendar c(QCalendar::Hebrew); QString hebrewDateString = c.toString(date); int hebrewYear = c.year(date); Maybe one could even integrate this into QLocale, that already provides support for localized month and day names? Cheers, Lars On 19/12/16 14:18, "Development on behalf of Soroush Rabiei" wrote: Can you elaborate on the reasons that prevent any change of that kind in QDate? Maybe they can be worked around? According to https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts Adding a member to struct or class is not possible without breaking ABI. On the other hand https://wiki.qt.io/Qt-Version-Compatibility suggests that Qt minor releases are backwards binary and source compatible. So there is no chance of touching QDate in Qt5 series. I'm working on a solution to provide calendar functionality without breaking ABI, while considering possibilities for Qt6 (keep minimum effort for converting current, temporary solution to futures Qt6 one). This may fail of course, There are too many details that need to be discussed. How we are supposed to change underlying calendar without adding information to QDate? Can we add arguments to all methods with a default value? Something like: QDate d; qDebug() << d.year(); // prints 2016 qDebug() << d.year(QCalendar::Jalali); // prints 1395 And then force relevant widgets/views to show/edit date and time on a specific calendar system: QDateEdit de; de.setDate(d); de.setCalendarSystem(QCalendar::Hebrew); // Is this possible? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On 2016-12-17, Soroush Rabiei wrote: > it's wrong to add such implementation to QDate. My view of QDate is this: > QDate represents a day in time. So it only needs to know what day it is > (how many days are to the day 0). And it is exactly things like that that would prevent partial date support in QDate (which is why I brought it up) /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
> > Can you elaborate on the reasons that prevent any change of that kind in > QDate? Maybe they can be worked around? > > According to https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts Adding a member to struct or class is not possible without breaking ABI. On the other hand https://wiki.qt.io/Qt-Version-Compatibility suggests that Qt minor releases are backwards binary and source compatible. So there is no chance of touching QDate in Qt5 series. I'm working on a solution to provide calendar functionality without breaking ABI, while considering possibilities for Qt6 (keep minimum effort for converting current, temporary solution to futures Qt6 one). This may fail of course, There are too many details that need to be discussed. How we are supposed to change underlying calendar without adding information to QDate? Can we add arguments to all methods with a default value? Something like: QDate d; qDebug() << d.year(); // prints 2016 qDebug() << d.year(QCalendar::Jalali); // prints 1395 And then force relevant widgets/views to show/edit date and time on a specific calendar system: QDateEdit de; de.setDate(d); de.setCalendarSystem(QCalendar::Hebrew); // Is this possible? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Saturday 17 December 2016 11:16:24 Thiago Macieira wrote: > On sábado, 17 de dezembro de 2016 17:13:38 PST Soroush Rabiei wrote: > > The idea is to remove all calendar > > calculation code out of the QDate (into QCalendarSystem possibly). I think > > QDate already has been bloated and knows more that it needs. Consequently, > > there is no chance to add other calendaring API into QDate, and I think > > it's wrong to add such implementation to QDate. My view of QDate is this: > > QDate represents a day in time. So it only needs to know what day it is > > (how many days are to the day 0). > > No chance of that ever happening. QDate will continue to support Gregorian > day, month, year, as well as ISO weeks. Support for other calendaring > systems (or maybe even other week systems) can be provided by a different > class, accessible from QDate and QLocale. Can you elaborate on the reasons that prevent any change of that kind in QDate? Maybe they can be worked around? Soroush's purpose is to allow the use of other calendar systems with minimum application changes (i.e. simply telling QDate to use a different date computation algorithm). I find his idea very attractive and not at odds with some other Qt classes. Your solution implies developers have to know about those calendars and are willing to support them in their applications. That's very unlikely to happen if they have to change lot of code and replace QDate with another class. As a developer, I don't want to know about the gory details of date computation with calendars I have never heard of. Adding "one month" to a date should use the same code whatever the underlying calendar is. The correct calendar to use should be a simple configuration parameter to make it as universally available as retrieving the local time irrespective of the user's location or generating the plural of a message in any language my application could be translated to even without my knowledge. Frederic ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
> > If you change QDate's internals, you have to wait for Qt 6. > > You can add to its API before then, though. > Hmm... I'll think of something else then. I thought these changes are backward compatible (API only), though it seems I'm mistaken. Maybe missing something about ABI compatibility: Adding a member will change memory layout and eventually client apps will be forced to recompile I suppose... > No chance of that ever happening. QDate will continue to support Gregorian > day, month, year, as well as ISO weeks. Support for other calendaring > systems > (or maybe even other week systems) can be provided by a different class, > accessible from QDate and QLocale. > > It will support Gregorian day, month, year of course, adding calendaring system will not change default behavior. But it will change if calendar is set to something else. Nevertheless, it seems not possible for QDate to change in semantics in anyway, not for Qt6 nor any release. Following these rules, we need a new design, without changing QDate interface nor its internals. I'm thinking of some changes in viewer widgets and view classes to change their current calendar (utilizing calendar classes and QLocale) without breaking compatibility. Cheers, Soroush ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On sábado, 17 de dezembro de 2016 17:13:38 PST Soroush Rabiei wrote:
> > I don't expect the calendaring system to require any changes to QDate
> > internals. It stores a Julian day, that's all.
>
> That's why we need to change QDate.
If you change QDate's internals, you have to wait for Qt 6.
You can add to its API before then, though.
> The idea is to remove all calendar
> calculation code out of the QDate (into QCalendarSystem possibly). I think
> QDate already has been bloated and knows more that it needs. Consequently,
> there is no chance to add other calendaring API into QDate, and I think
> it's wrong to add such implementation to QDate. My view of QDate is this:
> QDate represents a day in time. So it only needs to know what day it is
> (how many days are to the day 0).
No chance of that ever happening. QDate will continue to support Gregorian
day, month, year, as well as ISO weeks. Support for other calendaring systems
(or maybe even other week systems) can be provided by a different class,
accessible from QDate and QLocale.
> Some of my current changes to QDate are:
>
> int QDate::year() const
> {
> if (isNull())
> return 0;
> int year = 0;
> // Ask from QCalendarSystem what year we are in
> year = this->cs.yearFromJulianDay(jd);
> return year;
> }
There's no "cs" member and you cannot add one, so the above would be:
return QCalendarSystem::gregorian(*this).year();
> And also added two methods. This way I'm getting something like:
>
> int main(int argc, char *argv[])
> {
> QCoreApplication a(argc, argv);
> QDate date;
> date = QDate::currentDate();
> date.setCalendar(QCalendarSystem::Jalali);
You can't add this method.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
>
> I don't expect the calendaring system to require any changes to QDate
> internals. It stores a Julian day, that's all.
>
That's why we need to change QDate. The idea is to remove all calendar
calculation code out of the QDate (into QCalendarSystem possibly). I think
QDate already has been bloated and knows more that it needs. Consequently,
there is no chance to add other calendaring API into QDate, and I think
it's wrong to add such implementation to QDate. My view of QDate is this:
QDate represents a day in time. So it only needs to know what day it is
(how many days are to the day 0).
For example, QDate knows how many days are in a month, what are month names
(in case locale is not present), how to find leap years, and how to convert
a JulianDay to year, month and day in Gregorian calendar. Well, I think it
should only keep a Julian day, and (possibly) a handle to some external
resource (may be QCalendarSystem) that knows about calendar math. This
external resource will tell the QDate how to convert its Julian day to
current calendar. Please let me know if there is anything wrong with this.
Some of my current changes to QDate are:
int QDate::year() const
{
if (isNull())
return 0;
int year = 0;
// Ask from QCalendarSystem what year we are in
year = this->cs.yearFromJulianDay(jd);
return year;
}
And also added two methods. This way I'm getting something like:
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
QDate date;
date = QDate::currentDate();
date.setCalendar(QCalendarSystem::Jalali);
qDebug() << date.toString("/MM/dd");
qDebug() << date.toString("dd ");
qDebug() << date.toString();
return 0;
}
That prints this for me:
Starting
/home/soroush/workspace/build-test-jalali-date-Qt_5_8_0_qt5-Debug/test-jalali-date...
"1395/09/26"
"26 Azar 1395"
"Sat Aza 26 1395"
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Em quinta-feira, 15 de dezembro de 2016, às 21:10:19 PST, Sune Vuorela escreveu: > I think you need to touch quite some of the 'inner bits' of date / time, > and while you are there, I'd love if the design could make it easier to > implement my two missing pet features: > - Partial dates > - Date/time intervals/delta's. I don't expect the calendaring system to require any changes to QDate internals. It stores a Julian day, that's all. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Ch'Gans wrote: > Boost have them all: date/time, calendar, time zone, time period and > time duration > Date/Time is a very tricky subject, why not rely on boost implementation? > > http://www.boost.org/doc/libs/1_51_0/libs/locale/doc/html/group__date__time.html Because it would suck for Qt to depend on Boost. And because just using Boost directly in the applications (without a Qt wrapper) would mean dealing with a horrible API. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On 16 December 2016 at 10:10, Sune Vuorela wrote: > On 2016-12-15, Soroush Rabiei wrote: >> 2.History >> > > Hi > > I would welcome more calendar systems. Personally I hope for french > revolutionary calendar. Because it is funny. > > I think you need to touch quite some of the 'inner bits' of date / time, > and while you are there, I'd love if the design could make it easier to > implement my two missing pet features: > - Partial dates > - Date/time intervals/delta's. > > You might need the latter part for the implementation. > > (By partial dates, I mean e.g. my friend has birthday on november 1st. > every year. or unknown year.) > > (by date/time deltas, I e.g. I started working somewhere on november 1st > 2014. and stopped january 3rd 2015. How long did I work there) Boost have them all: date/time, calendar, time zone, time period and time duration Date/Time is a very tricky subject, why not rely on boost implementation? http://www.boost.org/doc/libs/1_51_0/libs/locale/doc/html/group__date__time.html Chris > > /Sune > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Thu, Dec 15, 2016 at 3:53 PM, Edward Welbourne wrote: > Soroush Rabiei wrote: > > Nowadays, almost all major programming frameworks support calendar > > globalization. We are a small group of developers working with > > non-Gregorian calendars and we believe Qt must support this too. This > > proposal discusses details of our plan (and early implementation) to > > add support for multiple calendar systems in Qt library. > > Excellent initiative. I've only had time for a cursory review (I'm > running away for mid-winter after today, not back until January, and > have a few other irons in the fire to get into a sensible state before I > go) so shall have to read in greater depth next year. However, one > thing did cross my mind in reading: > > How about having the QCalendarSystem object be an optional parameter to > various methods of QDate, that configures how it behaves, with the > default behaviour being that of the Gregorian system ? This has the > advantage that client code might be able to supply a custom > QCalendarSystem object, where an enum-based solution can only know about > the ones that the Qt project has chosen to support. > That's interesting. Please tell me more about your idea when you're back. I suppose adding new calendars by users, requires subclassing QDate? Or maybe somehow extend the enum that contains calendar systems[?]. I think adding the information on which calendar system is current date is on, can be added as a member (handlre/enum) to QDate. > > Presumably every calendar system can be referred back to the Julian date > [0], so most of the QCalendarSystem API would just implement methods > mapping Julian date to the chosen calendar's year, month, day &c. > > [0] which, lest anyone be confused, has nothing to do with the Julian > calendar - which *is* still in use ... > > That's correct for Persian, Islamic and Hebrew calendar AFAIK. There math behind is a more complex compared to Gregorian, but it will do it. I'm learning about other calendar systems, and it seems there will be no problem with having ant reference day as a date start point, for any calendar. > For the sake of anyone who hasn't understood why calendar system isn't > related to locale (or time-zone, or anything else particularly), note > that members of a culture that traditionally uses another calendar may > want to deal with a government-imposed (probably Gregorian) calendar > for all their work planning while using their culture's traditional > calendar when organising family and community events. A conference > centre organiser, furthermore, may want to be able to switch freely > between calendars to get a view of their diverse guests' perspectives in > order to avoid cultural gaffes and be ready to accommodate > complications. Even if there's nothing religious about the conference, > knowing that it happens to fall in Ramadan will prime the conference > centre staff to be ready to accommodate any attendees who won't be > eating during the hours of daylight, > > Eddy. > Exactly! Locale, Time Zone and Calendars can be used in any combination. We may want to have date and time in Persian calendar, written in German, on on CET +01:00 to celebrate Nowrooz in Berlin. And we must be able to have multiple calendars in one application. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Op 15/12/2016 om 22:10 schreef Sune Vuorela: On 2016-12-15, Soroush Rabiei wrote: 2.History Hi I would welcome more calendar systems. Personally I hope for french revolutionary calendar. Because it is funny. I think you need to touch quite some of the 'inner bits' of date / time, and while you are there, I'd love if the design could make it easier to implement my two missing pet features: - Partial dates - Date/time intervals/delta's. You might need the latter part for the implementation. (By partial dates, I mean e.g. my friend has birthday on november 1st. every year. or unknown year.) (by date/time deltas, I e.g. I started working somewhere on november 1st 2014. and stopped january 3rd 2015. How long did I work there) If memory serves me right: When, years ago, I tried to get the latter in, the work was a bit blocked because somebody else what working on... calendar support. :-) André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On 2016-12-15, Soroush Rabiei wrote: > 2.History > Hi I would welcome more calendar systems. Personally I hope for french revolutionary calendar. Because it is funny. I think you need to touch quite some of the 'inner bits' of date / time, and while you are there, I'd love if the design could make it easier to implement my two missing pet features: - Partial dates - Date/time intervals/delta's. You might need the latter part for the implementation. (By partial dates, I mean e.g. my friend has birthday on november 1st. every year. or unknown year.) (by date/time deltas, I e.g. I started working somewhere on november 1st 2014. and stopped january 3rd 2015. How long did I work there) /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Soroush Rabiei wrote: > Nowadays, almost all major programming frameworks support calendar > globalization. We are a small group of developers working with > non-Gregorian calendars and we believe Qt must support this too. This > proposal discusses details of our plan (and early implementation) to > add support for multiple calendar systems in Qt library. Excellent initiative. I've only had time for a cursory review (I'm running away for mid-winter after today, not back until January, and have a few other irons in the fire to get into a sensible state before I go) so shall have to read in greater depth next year. However, one thing did cross my mind in reading: How about having the QCalendarSystem object be an optional parameter to various methods of QDate, that configures how it behaves, with the default behaviour being that of the Gregorian system ? This has the advantage that client code might be able to supply a custom QCalendarSystem object, where an enum-based solution can only know about the ones that the Qt project has chosen to support. Presumably every calendar system can be referred back to the Julian date [0], so most of the QCalendarSystem API would just implement methods mapping Julian date to the chosen calendar's year, month, day &c. [0] which, lest anyone be confused, has nothing to do with the Julian calendar - which *is* still in use ... For the sake of anyone who hasn't understood why calendar system isn't related to locale (or time-zone, or anything else particularly), note that members of a culture that traditionally uses another calendar may want to deal with a government-imposed (probably Gregorian) calendar for all their work planning while using their culture's traditional calendar when organising family and community events. A conference centre organiser, furthermore, may want to be able to switch freely between calendars to get a view of their diverse guests' perspectives in order to avoid cultural gaffes and be ready to accommodate complications. Even if there's nothing religious about the conference, knowing that it happens to fall in Ramadan will prime the conference centre staff to be ready to accommodate any attendees who won't be eating during the hours of daylight, Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Calendar Systems proposal
1. Purpose Nowadays, almost all major programming frameworks support calendar globalization. We are a small group of developers working with non-Gregorian calendars and we believe Qt must support this too. This proposal discusses details of our plan (and early implementation) to add support for multiple calendar systems in Qt library. 2.History Originally there was four plans described in [1] based on ideas discussed in [2]. These talks (dated back to 2011) were never implemented and eventually abandoned. 3. Current Status Currently there is no support of any calendar system other than Gregorian. Gregorian calendar is widely used in western countries. However most countries in Middle-east, Asia and Africa use other calendar systems. Unfortunately there is no support for them. 4. Requirements Users of calendar systems expect same functionality provided by default calendar for their local calendar (at least we do so). Following list describes requirements of date/time API. 4.1. Such a feature must provide an API same as QDate, and all related classes. Adding convenient classed for each calendar type (QJalaliDate, QHebrewDate, QIslamicDate, etc.) will be discussed, Tough we believe any API without QDate integration will not satisfy our needs. 4.2. Backward compatibility must be kept in both public API and semantics of QDate, QDateTime and related classes. Such a feature must not affect any program that uses date, but has nothing to do with the calendar systems. A program compiled with Qt 5.9 must behave the way it do with 5.8, whether it utilizes calendar systems or not. There will be no assumption on user locale, nor the host system’s default calendar (as there is not any now). 4.3. The Public API and semantics of other parts of Qt that work with QDate, should not be changed. For instance, regardless of the calendar system that a QDate object uses, a QSqlQuery must be able to use it. And QVarient must be able to store/read it the way it did before. We prefer not to change private API and implementation as well, but if we had have to, (and it’s an affordable change) we will do it. For example we may need to change QtSql and QtCore classes to overwrite calendar system of QDate object to work properly. We hope we will find a way to avoid this. These examples are based on the assumption that QDate API will change, and calendar system support will be added directly to QDate (See S5 below) 4.4. Calendar systems and Locales, are irrelevant except month naming. There is nothing to do with the locales while implementing calendar system: Adding a new calendar is not about naming months for some locale. Some calendars are different in the math behind. For example, the year in Jalali calendar starts in 21st March. First 6 months are 31 days and next 6 months are 30 except 12th. Changing locale should not change calendar system. And there will be no information on calendar system in supported locales. (There is no default calendar in locale definition). It’s necessary to have multiple calendars at the same time in an application, and it’s necessary to have calendar system in all locales. Also calendar System and Time Zones are irrelevant. There were assumptions on previous plans (described in [1]) that are totally misunderstanding of the calendar systems. A particular plan was about adding calendar integration to QLocale, which we do believe is wrong in all aspects. Because calendar system has nothing to do with culture. A calendar is an abstract astronomical concept. 5. API Candidates The plan is to implement support for at least five most-used calendar systems. Each calendar’s implementation will be added into a new class named `QCalendarSystem`. This class will provide information on calendar system details, like how many days are in each month and if a year is leap year or normal. This class will also contain the calculation code needed for QDate. Most importantly, how to convert between julian day and calendar date. Currently these calculations are implemented in QDate class (qtbase/src/corelib/tools/qdatetime.cpp). There are several candidates for date object APIs. Following list discusses these APIs. 5.1. Integrate calendar system semantics into QDate This is what we plan to do. There are several ways to do this. All of course will preserve backward compatibility. First three options are based on John Layt’s ideas described at [3] 5.1.1. Add a calculator class, add convenience methods to QDate QDate myDate = QDate::gregorianDate(2000, 1, 1); QDateCalculator myCalc; int localYear = myCalc.year(myDate); QString localString = QLocale::system().toString(myDate); QDateTimeEdit myEdit(myDate); myCalc.setCalendar(QLocale::HebrewCalendar); int hebrewYear = myCalc.year(); There are several issues with this API. Most importantly it does not preserve backward-compatibility of QDate API. This also does not meet the requirement of having QDate-like API. 5.1.2. Add new methods
