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

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

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: > >

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: > >

[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

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

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 ___

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 >>

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

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

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

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 >

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

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

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:

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

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:

[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

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

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

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

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 >

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: >

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

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

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

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

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

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

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

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

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

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

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

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

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 ?

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

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

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

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

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

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

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:

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.

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 > -

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

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

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

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

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,

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

[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