On the need for Calendaring in addition to Locale support

[Soroush Rabiei]

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

(list: http://lists.gnu.org/archive/html/bug-coreutils/2008-06/msg00185.html)

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]

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:

– `com.ibm.icu.util.Calendar`;

– `com.ibm.icu.text.DateFormat`;

– `com.ibm.icu.text.NumberFormat`;

– `com.ibm.icu.text.MessageFormat`.

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]

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

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]

 

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]

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]

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]

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]

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]

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

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. 

[1]: https://docs.oracle.com/cd/B10501_01/appdev.920/a96584/oci03typ.htm#421890

[Ameretat Reith]

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]

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]

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. 

[1]: https://www.facebook.com/help/community/question/?id=10151688445780923

 

[Shervin Afshar]

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]

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]

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.