On the need for Calendaring in addition to Locale support

42 views
Skip to first unread message

Soroush Rabiei

unread,
Sep 24, 2017, 2:59:17 PM9/24/17
to Persian Computing
Hello everyone, 

I assume that we all do agree on the fact that localization (specifically on 
calendaring) has been fallen short to meed our needs in modern digital 
computation environments.

There are of course many successful attempts to add non-gregorian calendaring 
support to existing software as a plugin/new feature, or patch them. And many 
other independent implementations that we truly do appreciate.

Unfortunately, despite all these contributions, we're not there yet. We do not 
have "good", "seamless" calendaring integration in our everyday software. 
There are extensions, patches, plugins, or even hacked versions of various 
software, but there is not many tools that have "calendaring" as a core 
feature, or have provided interfaces for third-parties to implement their own 
calendar.

I do believe that the root of this problem is the fact that "calendar type" is 
not widely accepted as a core concept of software localisation (just like 
"verbal variety", "number format" and others). This leads developers through 
the implicit assumption that there is no need to provide any localization means 
for their date/time API (while they do provide such means for string 
translation for example).

As an example take GNU's coreutils package. There we have a `date' utility 
which respects locale (as in POSIX) and provides date/time formatting options 
on user locale:

  $ LANG=en_GB date +"%c"
  $ Sun Sep 24 12:44:55 2017
  $ LANG=fa_IR date +"%c"
  $ یکشنبه ۲۴ سپتامبر ۱۷، ۱۲:۴۴:۵۵

It could have been like this:

  $ LANG=en_GB date -j +"%c" # note `-j' argument
  $ Sun Meh 96 12:44:55 2017
  $ LANG=fa_IR date -j +"%c" # note `-j' argument
  $ یکشنبه ۲ مهر ۹۶، ۱۲:۴۴:۵۵

  
But there is no support for non-gregorian calendars. No one ever requested such 
a feature. There is just a single post from 2008 which in Mr. Tofighi suggests 
that `date' command should support Persian (=Solar Hijri) and Hijri calendars. 
He even provides an initial implementation sample. Though developers suggest 
that Persian calendar is astronomical and can not be caught in formula (which is 
not correct, and there is tabular versions of course).


I think `date' could be a good starting point to press on the idea that the 
"locale" concept should cover calendar too. I volunteer to develop Solar Hijri, 
Hijri and Jewish calendars into `date' program. This functionality will not 
break existing interface, but the idea will encounter resistance from community.

What do you think about having calendar support in date? I would like to hear 
from you about this before I start the task or contact GNU devs in list.

Note: I don't suggest that the "calendar in use", should have been part of the 
user/system locale. Though I think "calendar" must be considered as a part of 
localization process (Even having no standardized interfaces and protocols).

Cheers,
-Soroush

Shervin Afshar

unread,
Oct 5, 2017, 12:56:33 PM10/5/17
to Soroush Rabiei, Persian Computing
On Sun, Sep 24, 2017 at 2:58 AM, Soroush Rabiei <soroush...@gmail.com> wrote:
 
Unfortunately, despite all these contributions, we're not there yet. We do not 
have "good", "seamless" calendaring integration in our everyday software. 

In my opinion, support for Solar Hijri has not been a priority for most of major commercial software developers outside of the Greater Iran. For FOSS, the story is probably different and it might summarize to lack of community support. 
 
There are extensions, patches, plugins, or even hacked versions of various 
software, but there is not many tools that have "calendaring" as a core 
feature, or have provided interfaces for third-parties to implement their own 
calendar. 

I do believe that the root of this problem is the fact that "calendar type" is 
not widely accepted as a core concept of software localisation (just like 
"verbal variety", "number format" and others). This leads developers through 
the implicit assumption that there is no need to provide any localization means 
for their date/time API (while they do provide such means for string 
translation for example).

That is not true. Support for locale-specific calendars are one of the essential features of world-ready software and libraries. As an example, if you check the documentations for Unicode ICU library, you'd be surprised how extensive is the support for non-Gregorian calendars (hint: observational Islamic and Umm al-Qura are supported) in that library. The same goes for number formatting or advanced message formatting (if it was what you meant by "verbal variety"). Check out the following ICU4J classes for more details:


As a reference—and to exhibit the ease of use—I'll include a code-example of Solar Hijri usage in ICU4J at the end of this email.

There is a whole industry built around assisting the developers to overcome their biases and take more informed technical decisions regarding how global software ought to be designed and built.
  
What do you think about having calendar support in date? I would like to hear 
from you about this before I start the task or contact GNU devs in list.

It is a good idea. Probably maintainers of `coreutils` are now more receptive (and better informed) than back in 2008.

## A bit of Groovy to demonstrate Solar Hijri date formatting in ICU4J 

@Grapes(@Grab(group='com.ibm.icu', module='icu4j', version='58.1'))

import com.ibm.icu.util.ULocale
import com.ibm.icu.text.DateFormat

print DateFormat.getDateInstance(DateFormat.FULL, new ULocale("fa_IR@calendar=persian")).format(new Date());

Ameretat Reith

unread,
Oct 5, 2017, 1:41:45 PM10/5/17
to Shervin Afshar, Soroush Rabiei, Persian Computing
>> What do you think about having calendar support in date? I would like to
>> hear
>> from you about this before I start the task or contact GNU devs in list.
>
>
> It is a good idea. Probably maintainers of `coreutils` are now more
> receptive (and better informed) than back in 2008.

I don't think solar-hijri aware `date` would have much advantage over
already existing tools like `jdate` [1]. I think an ideal approach is
to have a multi-calendar libc implementation. That may look a big
extension to POSIX but let dream we have a calendar aware `strftime`;
we could then get output of `ls`, `date` or some-other-legacy tool in
calendar of choice by just setting some new localization environment
variable without changing much code in those tools. Also consider even
in same calendar, month names differ between languages ("مهر" is
"میزان" in Afghanistan) as they do in Gregorian calendar and we
already have this language specific translations for Gregorian
calendar in locales' definition files, so we could extend them for new
calendars.

1: Assuming Birashk's method used in `jcal` to be correct but It's
another story. http://www.nongnu.org/jcal/jdate.html

Soroush Rabiei

unread,
Oct 5, 2017, 2:36:55 PM10/5/17
to Persian Computing
In my opinion, support for Solar Hijri has not been a priority for most of major commercial software developers outside of the Greater Iran. For FOSS, the story is probably different and it might summarize to lack of community support.

Well said. I agree with you on "lack of community support".
 
That is not true. Support for locale-specific calendars are one of the essential features of world-ready software and libraries. As an example, if you check the documentations for Unicode ICU library, you'd be surprised how extensive is the support for non-Gregorian calendars (hint: observational Islamic and Umm al-Qura are supported) in that library.
 
No I'm not surprised. I'm aware of the ICU and I already integrated Islamic 
Civil and Solar Hijri calendars from ICU into Qt 5.11. There are dozens of other 
implementations and most notably the ICU library, but that's not the point I'm 
trying to emphasize. My point is that they are not "integrated" into our 
everyday software - especially programming frameworks and "core" utils. As an 
example, despite the fact that Qt is depended on ICU it has no support for 
non-Gregorian calendars. 

What is the use of ICU having nong-Gregorian support? When, for example, no major 
DBMS vendor (Free or not) supports ICU calendaring in its connection library. 
And there is no major programming framework (Qt for example) have integrated 
calendaring in their date/time API or GUI elements.

It is a good idea. Probably maintainers of `coreutils` are now more receptive (and better informed) than back in 2008.

 I'll try and implement ICU-based calendaring support in GNU coreutils.

Cheers,
Soroush

Hedayat Vatankhah

unread,
Oct 5, 2017, 4:56:32 PM10/5/17
to Ameretat Reith, Shervin Afshar, Soroush Rabiei, Persian Computing

 


Ameretat Reith wrote on Thu, 5 Oct 2017 21:11:43 +0330:
What do you think about having calendar support in date? I would like to
hear
from you about this before I start the task or contact GNU devs in list.

It is a good idea. Probably maintainers of `coreutils` are now more
receptive (and better informed) than back in 2008.
I don't think solar-hijri aware `date` would have much advantage over
already existing tools like `jdate` [1]. I think an ideal approach is
to have a multi-calendar libc implementation. That may look a big
extension to POSIX but let dream we have a calendar aware `strftime`;
we could then get output of `ls`, `date` or some-other-legacy tool in
calendar of choice by just setting some new localization environment
variable without changing much code in those tools. Also consider even
in same calendar, month names differ between languages ("مهر" is
"میزان" in Afghanistan) as they do in Gregorian calendar and we
already have this language specific translations for Gregorian
calendar in locales' definition files, so we could extend them for new
calendars.
IIRC, it is very unlikely to happen in glibc (unless it is added either to POSIX or C standard). Probably what can be done is to create a separate library which provides libc compatible variants with full calendar support and try to promote it among main FOSS projects, specially the 'base' ones like Qt, GTK/Glib, ... .

Shervin Afshar

unread,
Oct 5, 2017, 5:48:04 PM10/5/17
to Soroush Rabiei, Persian Computing

On Thu, Oct 5, 2017 at 11:24 AM, Soroush Rabiei <soroush...@gmail.com> wrote:

What is the use of ICU having nong-Gregorian support? When, for example, no major 
DBMS vendor (Free or not) supports ICU calendaring in its connection library. 
And there is no major programming framework (Qt for example) have integrated 
calendaring in their date/time API or GUI elements.

May be there is no pressing need for the DBMSes and frameworks to get into that much of detail in so low a level in the tech stack? For instance, I don't store my date/times as Solar Hijri in datastores. I store them as epoch and convert them (with adequate caching) based on users' selected locales and TZs. What is your common use-case of "ICU calendaring" in datastore connector?

C++ is not my cup of tea so I don't know much about QT, but in presence of well-established libraries which neatly extend programming frameworks where needed (many ICU4J classes extend Java's native abstracts) , I totally understand the decision by the architects of those frameworks to not to get involved with i18n.

Ameretat Reith

unread,
Oct 6, 2017, 4:41:51 AM10/6/17
to Hedayat Vatankhah, Persian Computing
It's doable. Actually I just made a tiny manipulation in jcal's
`jtime.c` to forward `strftime` and `localtime` to their `jdate`
variants. Now I can almost get `date` output in Solar Hijri by
preloading this new library (Only year is incorrect because libjalali
time structures holds year number as absolute but glibc holds years
passed since 1900)

Soroush Rabiei

unread,
Oct 6, 2017, 12:55:55 PM10/6/17
to Persian Computing

May be there is no pressing need for the DBMSes and frameworks to get into that much of detail in so low a level in the tech stack?

They should. If there is locale support, then there must be calendaring support too.
 
For instance, I don't store my date/times as Solar Hijri in datastores. I store them as epoch and convert them (with adequate caching) based on users' selected locales and TZs.

What do you mean by "I don't store my date/times as Solar Hijri"? You don't 
store date/time in any specific calendar. There is no calendaring concept in 
DBMS time fields. Underlying database engine stores date and time in epoch 
delta. You "tell" the connector library (not DBMS) to store your date and time 
and it converts it to epoch delta and sends it to DBMS in binary format. The 
connector library parses SQL statements and generates epoch delta from 
**Gregorian** calendar:

    INSERT INTO table VALUES ('sample string', '2017-10-06') ; -- Actually stores 2458032

It could have been:

    INSERT INTO table VALUES ('sample string', FROM_SOLARH('1369-07-14')) ; -- Stores 2458032 too
 
What is your common use-case of "ICU calendaring" in datastore connector?

There are many many use cases of calendar-aware SQL statements. As an example  
you may want to join tables or accumulate your columns then group them by Solar 
Hijri month number. That makes sense in report generators and many other 
software. Here is one of mine:  

    SELECT 
        jyear AS `year`,
        jmonth AS `month`,
        jday AS `day`,
        COUNT(1) AS `all`,
        SUM(`class` < 6) AS `light`,
        SUM(`class` > 5) AS `heavy`,
        100.0 * SUM(`class` < 6) / COUNT(1) AS `light_freq`,
        100.0 * SUM(`class` > 5) / COUNT(1) AS `heavy_freq`,
        AVG(`speed`) AS `average_speed`,
        SUM(`speed` * (`class` < 6 AND `overspeed` = TRUE)) / SUM(`class` < 6 AND `overspeed` = TRUE) - 
                (select `speed_limit` from configs) AS `overspeed_factor`,
        SUM(`overweight` = TRUE) AS `overweight`,
        SUM(`overweight_axle` = TRUE) AS `axis_overload`
    FROM
        `records` where `lane`=2
    GROUP BY `month` , `day`; 

You see? I *HAVE TO* store three digits in table in order to provide suitable 
reporting for my customer. There are stored procedures that provide similar 
functionality using much simpler SQL statements, but they are about 100x slower.

The *natural* place to support calendaring is in connector libraries. They can 
parse statements and provide optimized broken-down statements for DBMS.  

I totally understand the decision by the architects of those frameworks to not to get involved with i18n.

I don't. There is a huge effort to support i18n and l10n in programming 
frameworks and even database connectors. There are translation schema in GNU, Qt 
and even .NET. I think there should be calendaring too.  It's not that complicated or 
diverse to support. 

Just like DBMS example, the natural place to insert calendaring support is in 
the programming API itself. You can't integrate calendars into GUI without having 
calendar-aware QDate/QDateTime API, even having ICU or any other library.

Cheers,
Soroush 
 

Shervin Afshar

unread,
Oct 6, 2017, 1:58:52 PM10/6/17
to Soroush Rabiei, Persian Computing

On Fri, Oct 6, 2017 at 3:32 AM, Soroush Rabiei <soroush...@gmail.com> wrote:
 
For instance, I don't store my date/times as Solar Hijri in datastores. I store them as epoch and convert them (with adequate caching) based on users' selected locales and TZs.

What do you mean by "I don't store my date/times as Solar Hijri"? You don't 
store date/time in any specific calendar. There is no calendaring concept in 
DBMS time fields. Underlying database engine stores date and time in epoch 
delta. You "tell" the connector library (not DBMS) to store your date and time 
and it converts it to epoch delta and sends it to DBMS in binary format. The 
connector library parses SQL statements and generates epoch delta from 
**Gregorian** calendar:

That is correct if one chooses to use "DBMS time fields" (DATETIME type or alike), but that's not what I was intending to exhibit. What I wanted to show was that one doesn't have to rely at all on database engine or connector library for any logic in dealing with time and date data. Then since one doesn't rely on those feature of database engine and connector library to deal with time and dates (comparison, ordering, etc.), it would be possible to store time and date data in epoch *as a string or bigint*, then convert to whatever calendar and/or timezone needed in higher-levels which have decent support for such operations. This is specifically a useful pattern with the proliferation of non-relational datastores. This might not be for you if you are relying on DBMS for sorting and comparing and creating direct reports from SQL queries or stored procedures.

Let's assume that I actually choose to store stuff in DATETIME in my DB, then what I prefer to do is to store everything in Gregorian and convert on retrieval with the libraries I use.
 
It could have been:

    INSERT INTO table VALUES ('sample string', FROM_SOLARH('1369-07-14')) ; -- Stores 2458032 too

Yeah...it could, but I don't think that would be happening any time soon.

You see? I *HAVE TO*  

Geez....chill out! No need to shout!

Ameretat Reith

unread,
Oct 6, 2017, 2:05:35 PM10/6/17
to Soroush Rabiei, Persian Computing
>> For instance, I don't store my date/times as Solar Hijri in datastores. I
>> store them as epoch and convert them (with adequate caching) based on users'
>> selected locales and TZs.
>
>
> What do you mean by "I don't store my date/times as Solar Hijri"? You don't
> store date/time in any specific calendar. There is no calendaring concept in
> DBMS time fields. Underlying database engine stores date and time in epoch
> delta. You "tell" the connector library (not DBMS) to store your date and
> time
> and it converts it to epoch delta and sends it to DBMS in binary format. The
> connector library parses SQL statements and generates epoch delta from
> **Gregorian** calendar:

That's not true. Not only some DBs coming with datetime type store
time in calendrical form, at-least one of them gives you a choice
between calendars (like Solar Hijri); It's Oracle! [1]
In MySQL, you can just use MONTH function on date field and I think
It's optimized because It just needs a mask to get month number.

1: Though It's not much flexible, you can have just one calendar in
whole DB instance.

Soroush Rabiei

unread,
Oct 10, 2017, 4:37:05 AM10/10/17
to Persian Computing
That's not true. Not only some DBs coming with datetime type store
time in calendrical form, at-least one of them gives you a choice
between calendars (like Solar Hijri); It's Oracle!
 
Yes, and it's great feature makes everything easier. (Even though it's buggy in 
conversion algorithms and IRDT/IRST handling).
 
 In MySQL, you can just use MONTH function on date field and I think 
It's optimized because It just needs a mask to get month number.
 
You're right. MySQL's `DATE' type is broken-down date (3 bytes as YYYY×16×32 + 
MM×32 + DD) but `TIMESTAMP' is seconds since the epoch (UTC). I mostly use 
TIMESTAMP (having more limitations) only because I can provide calendaring more 
efficiently. 

Most modern DBMS's provide both, and I will be happy even if calendaring support 
were only available for epoch-delta-based fields. (It can be provided for 
broken-down fields too)

My approach is not to touch any of storage types (which will break everything) 
but to provide means to handle conversions in SQL side (either connector 
library, parser, or DBMS core). That way we can have optimisation which we are 
unable to provide in application layer date/time hacks (my previous SQL 
statement is a proof of this claim). This is the reason that we need to have 
calendaring in core APIs (Programming Frameworks, DBMS cores, etc) not in 
separated libraries/tools. 

1: Though It's not much flexible, you can have just one calendar in
whole DB instance.

I guess that's because Oracle DB stores date and time in broken-down bitfield format [1], and this is only possible in a per-schema manner. 

Ameretat Reith

unread,
Oct 10, 2017, 5:08:09 AM10/10/17
to Soroush Rabiei, Persian Computing
On Tue, 10 Oct 2017 01:28:11 -0700 (PDT)
Soroush Rabiei <soroush...@gmail.com> wrote:

> >
> > That's not true. Not only some DBs coming with datetime type store
> > time in calendrical form, at-least one of them gives you a choice
> > between calendars (like Solar Hijri); It's Oracle!
>
>
> Even though it's buggy in conversion algorithms and IRDT/IRST handling

I wanna stress this a bit because It's the point everything go nasty.
There is a big difference between using calendrical form and timestamp
and It's calendars are based on governments laws and are subject to
change, for example, In Iran we swapped using or not using day light
saving couple of times in a half decade. At some point your application
may need to be updated according to law changes, but application
libraries are much easier and more likely to change in time than
databases. It's much easier to update `pytz` than MySQL in a update
procedure and It's more likely to actually do the necessary change.

So if you happen to make a critical system, you may want consider
these things. It may be better just do little or nothing calendaring
stuff in DB, just store timestamp in DB and cache everything you want
in other fields. Make a correct system and then optimize it by what you
have, It's my choice.

Soroush Rabiei

unread,
Oct 10, 2017, 5:22:39 AM10/10/17
to Persian Computing
That is correct if one chooses to use "DBMS time fields" (DATETIME type or alike), but that's not what I was intending to exhibit. What I wanted to show was that one doesn't have to rely at all on database engine or connector library for any logic in dealing with time and date data.
 
one DOES have to rely on database engine or connector library for SOME 
logic in dealing with time and date data: How can we use aggregate functions 
(which is widely used in reporting) on date-time fields? 

Let's assume that I actually choose to store stuff in DATETIME in my DB, then what I prefer to do is to store everything in Gregorian and convert on retrieval with the libraries I use.

The problem is not conversion. We all can do conversions. Having calendaring in 
your application side, you will have to provide code for logic which its natural 
place is within data layer. I don't even mention performance issues...

Let's say I have a database of 250M Iranian citizens born between 1920 and 2017 
and I wan't to calculate average lifetime of these people, grouped by their month of 
birth-- in Solar Hijri calendar. I wonder what you will suggest for GROUP BY or 
HAVING statements without multiplying number of your statements by 97. I would 
do something like this one: (please replace functions with your favourite 
DBMS syntax, and ignore SQL errors)

    SELECT AVG(TO_YEAR(DATEDIFF(DOB, DOD))) FROM personal_info
    WHERE DOD IS NOT NULL 
    GROUP BY MONTH(DOB)

This applies to programming frameworks and tools too. let's say I would like 
to use Solar Hijri calendar in my Qt GUI application, adn I already know how to 
do the math. Then how can I provide QCalendarWidget-like look and feel?


Soroush Rabiei

unread,
Oct 10, 2017, 5:38:03 AM10/10/17
to Persian Computing
I wanna stress this a bit because It's the point everything go nasty.
There is a big difference between using calendrical form and timestamp
and It's calendars are based on governments laws and are subject to
change, for example, In Iran we swapped using or not using day light
saving couple of times in a half decade. At some point your application
may need to be updated according to law changes, but application
libraries are much easier and more likely to change in time than
databases. It's much easier to update `pytz` than MySQL in a update
procedure and It's more likely to actually do the necessary change.

That's not specific to non-gregorian calendars. Facebook once did the 
mistake [1] and now they're not sure when exactly did things happened (when it 
comes to different timezones). Another great example is inter-banking 
communication system of Iran. The entire finance system is dead for two long 
hours in a year! Anyway,  I'd just store and process all the dates in UTC and 
make sure that the GUI displays it according to the user time-zone (or multiple 
timezones).

So if you happen to make a critical system, you may want consider
these things. It may be better just do little or nothing calendaring
stuff in DB, just store timestamp in DB and cache everything you want
in other fields. Make a correct system and then optimize it by what you
have, It's my choice.

Yep... I would like to see calendaring stuff, first in epoch-based fields. Then 
in broken-down fields (and their corresponding functions). It's up to the user 
to take care about correct choice of data type and maintain integrity of 
critical systems. 

 

Shervin Afshar

unread,
Oct 10, 2017, 12:56:32 PM10/10/17
to Soroush Rabiei, Persian Computing
On Tue, Oct 10, 2017 at 2:18 AM, Soroush Rabiei <soroush...@gmail.com> wrote:
one DOES have to rely on database engine or connector library for SOME 
logic in dealing with time and date data: How can we use aggregate functions 
(which is widely used in reporting) on date-time fields? 

Sure. Use it if you think you have to. I'm more in agreement with what Ameretat Reith mentioned, and prefer to stick to calendar-aware, reporting helpers implemented in higher technology stack layers.
 
The problem is not conversion. We all can do conversions. Having calendaring in 
your application side, you will have to provide code for logic which its natural 
place is within data layer. I don't even mention performance issues...

"natural"? Having rules of thumb of abstraction in mind, I'd say that having calendarical conversion logic in the DB engine is probably the least "natural" place for that logic. I would like to isolate my data from the irregularities of calendrical systems (e.g. countries switch calendars, they might even have more than one and values in all of different calendars are required in some situations). 

Re: Performance. If you rely on a single conversion channel in your application for the any sort of data conversion with no caching and no distributed processing power, of course, you should expect performance issues. Distributed big-data technologies/libraries like Presto are your friends.

Soroush Rabiei

unread,
Oct 10, 2017, 4:28:03 PM10/10/17
to Persian Computing
Sure. Use it if you think you have to. I'm more in agreement with what Ameretat Reith mentioned, and prefer to stick to calendar-aware, reporting helpers implemented in higher technology stack layers.
"natural"? Having rules of thumb of abstraction in mind, I'd say that having calendarical conversion logic in the DB engine is probably the least "natural" place for that logic. I would like to isolate my data from the irregularities of calendrical systems (e.g. countries switch calendars, they might even have more than one and values in all of different calendars are required in some situations). 

But... There is a calendar API in database core DBMS design. And it have all the 
complexity you mentioned: Missing 11 days in 1752, complex leap rules and all 
stuff. But it's there. Inside the DBMS. And if any other calendar is ever going 
to be supported on any DBMS, I think the *natural* place to put the logic is 
inside DBMS. Just like what Oracle did and what I'm doing in Qt and what I think 
should be done in GNU coreutils.  

Important note: Locale and Calendar are completely different / unrelated 
concepts and should not be handles with same logic. Let's focus on what we 
already know about locale: Countries don't have calendars. They have writing 
systems, date-time formats, languages, etc. These form a locale settings. 

We already discussed this on Qt mailing list [1]
 
Re: Performance. If you rely on a single conversion channel in your application for the any sort of data conversion with no caching and no distributed processing power, of course, you should expect performance issues. Distributed big-data technologies/libraries like Presto are your friends.

Your argument is invalid my friend. Performance has nothing to do with 
technology in this context. It's a design decision that could have saved MIPSs 
no matter on which processor, machine, architecture or infrastructure. The 
bigger the machine, the more the MIPS and development hours would be saved. I'm 
talking about the design.  

So... Let's handle my little unimportant case before climbing clouds:

I have a small road-management monitoring software on an 8 core Windows Server 
machine, having its MySQL database on same installation. Windows..., 16GB 
RAM..., Low-Speed HDD... I don't have cloud and I can't connect road 
administration station to high speed internet. The query that I wrote for yearly 
reporting is 100x times slower for solar Hijri Calendar.

[1] quote:

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. 

......

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,

Shervin Afshar

unread,
Oct 10, 2017, 4:37:41 PM10/10/17
to Soroush Rabiei, Persian Computing
On Tue, Oct 10, 2017 at 1:28 PM, Soroush Rabiei <soroush...@gmail.com> wrote:

So... Let's handle my little unimportant case before climbing clouds:

I have a small road-management monitoring software on an 8 core Windows Server 
machine, having its MySQL database on same installation. Windows..., 16GB 
RAM..., Low-Speed HDD... I don't have cloud and I can't connect road 
administration station to high speed internet. The query that I wrote for yearly 
reporting is 100x times slower for solar Hijri Calendar.

According to what you said so far and your attitude, I don't have anything else to add to this conversation. Good luck with your development.
Reply all
Reply to author
Forward
0 new messages