search

HowardHinnant / date

A date and time library based on the C++11/14/17 <chrono> header
Other
3.15k stars 683 forks source link

Library extension and Multi-Calendar support. #166

Closed ghost closed 7 years ago

ghost commented 7 years ago

I open a new issue for this question. I see that the date project contains in addition to the basic Gregorian calendar, a Julian and Islamic calendar.

The first point that comes to mind, but I do not yet master all the subtlety of your (really good) project, is that there is redundancy in the namespaces containing the auxiliary calendars code. Simple question, is it not possible to use the inheritance capabilities of C ++ to simplify the addition of new calendar where most methods can be inherit from the date base class?

The second point that comes to mind is the intrication of the code of the extra calendars with the base code of the library. Indeed, this is not currently a problem since it is about arithmetic calendars. But what about the evolution towards astronomical calendars (lunar, luni-solar, solar)?

I've already code a lot of calendars where the interaction is based on the Julian Day (from, to fixed reference JD). I think to rewrite the algorithms using a more precise astronomical library (my choice is simple : the SOFA (Standard Of Fundamental Astronomy)) for the common astronomical routines : Equation of Equinoxes, Nutation, .... Some of the calendars are geolocalisation based (related to a position around the globe at 'epoch') and need to refere to geodetic datums. For that some great third-party projects are available like PROJ4 (to cite only this one).

Thus, I think the best way is put the calendars on top of the current design (on top of tz in reference of your slide) as an external extension of the current library but using the same powerfull functionnalities.

I therefore submit the idea (for the future) to keep only the Julian and Gregorian calendars in the basic librarie and to create an additional calendar project based entirely on the date project but using third-party dependencies and incorporating new arithmetic calendar but also other astronomical calendars. Knowing that, logically, the majority of users of date will use the many functionality of the Gregorian calendar without worrying about specific calendars.

This is only a proposal.

EDIT: One other modification can be at time level. At the moment, the tz.h contains some "clock" functionalities (local, UTC, TAI ...). For design and semantic coherence questions, theses codes can be moved to a single header time.h. This file can be extended to other time standard like : UT1, TT, TCB, TDB, TCG ... most of theses are astronomical related and the extension can be a part of a possible calendar project.

HowardHinnant commented 7 years ago

I agree that there is a considerable amount of duplication in the current calendars. I'm very hesitant to use inheritance to create a new calendar unless it can be done without the danger of confusing one calendar with another. For example it is very important that Julian::year be a distinct type from date::year because it would be very easy for humans to conflate these two definitions, but they are truly distinct. For instance there are instants in time when the value of Julian::year will not be the same as date::year.

I have similar concerns for all of the calendar types and all of the calendars (month, day, etc.). Where the calendar types do perfectly align, I'm happy to go with a type alias, as opposed to inheritance.

You should also understand that this library is being proposed for standardization, but not the extra calendar types. For the purpose of standardization, date.h and tz.h are reference implementation for the purpose of gathering field experience. And iso_week.h, julian.h and islamic.h are example user-written calendars meant to demonstrate that users of the std::lib will be able to write their own calendars, and have them interoperate with the std::lib chrono library.

I view calendars akin to iterators. The std::lib defines some, and users write their own. As long as they all conform to the std-defined concept of iterators, then they can all work with other std::lib components such as <algorithm>. In the case of calendars, it is chrono::time_point<system_clock, days> that I am seeking universal interoperability with.

More calendars in other projects seems like a great idea to me. I would love to see that. Here's another such potential calendar: https://stackoverflow.com/q/44735322/576911

ghost commented 7 years ago

OK, the heart of the project is intented to become a part of the STL ... I say wonderful. And it's another motivation to work on this great library. The other is that I need a very complete calendar library for my own project - a software for the historian where datation is something primordial.

This is not really the biggest part of the software, but this need to be powerfull. That why the flexibility of your concept attracted me. There's a lot of ISO 8601 implementation in many langage, but no one is really complete and flexible like yours. No one so close to the standard and for instance, to chrono.

I perfectly understand your chilliness to used c++ inheritance and my point of view was superficial, for now I have only diagonaly read your code. I imagine that was thought and sometimes flexibility requires compromises like this.

About the calendars, I've implemented a lot of calendars in C++ using my own implementation of Meeus/Duffett-Smith [1/2][3/4] astronomical algorithms and from Derschowitz/Reingold [5] "Calendrical Calculation" books. But the implementation is not so flexible.

First, the Meeus/Duffett-Smith algorithms are approximations - good approximations - but approximations. That why writing a C++ version of the C-like routines of the SOFA (http://www.iausofa.org/) is the best way to get good precision by using the standard resolution of the IAU (International Astronomical Union).

Note that the precision is relative. As you certainly know, in astronomy calculation, 
the precision tends to decrease as the temporal distance increases. The validity period 
of the algorithms is of the order of +/- 4000 years from now. Outside this period, the error 
grows exponentially. It is often the number of terms in polynomial equations that define 
precision, and these terms are necessarily limited. On the scale of the universe, our spatio-
temporal landmarks are ridiculous. Besides, time is only convention, not a stallion. 
But we are here in philosophical or metaphysical concepts.

Secondly, the "Millenium Calendar" book describe the algorithms and datas for approximately thirty of usefull calendars but there's a lot of anothers calendars to be implemented, take a look to the wikipedia : https://en.wikipedia.org/wiki/List_of_calendars. Some "esoteric"/"pagan" calendars are not referenced, let me say Masonic calendar "Anno Lucis" for example (maybe the most simple to implement for the little story). That why, working on a complete and eclectic calendar library is not only a coding work, but a historical research work.