Re: [Development] Calendar Systems proposal

[Ch'Gans]

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

[Soroush Rabiei]

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

[André Somers]

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

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

/Sune

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Calendar Systems proposal

[Edward Welbourne]

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

[Soroush Rabiei]

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 

Re: [Development] Nominating Teemu Holappa for Approver and Maintainer status.

[Alexander Blasche]

Congratulations to Teemu. His rights have been adjusted.

--
Alex


From: Development  
on behalf of Gatis Paeglis 
Sent: Thursday, 24 November 2016 2:00:32 PM
To: development@qt-project.org
Subject: [Development] Nominating Teemu Holappa for Approver and Maintainer 
status.

Hi,

I'd like to nominate Teemu Holappa for the Approver status. He joined Digia 
(now The Qt Company) 3+ years ago as a Qt consultant. Teemu has contributed to 
meta-boot2qt and anything else that needs fixing to get Qt for Device Creation 
releases out the door.

Here is his gerrit dashboard:

https://codereview.qt-project.org/#/q/owner:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z

Teemu also has done a good job at reviewing changes for meta-{boot2qt, qt5, 
mingw} among other projects:

https://codereview.qt-project.org/#/q/reviewer:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z

I'd also like to nominate him as the Maintainer of the qtdeviceutilities module 
(http://code.qt.io/cgit/qt/qtdeviceutilities.git/). Teemu has heavily 
refactored this module and added significant amount of new features. He is the 
go-to guy in the team when qtdeviceutilities is the topic.


Gatis Paeglis.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development