Clarify the 'origin' for date and datetime types when working with the Gregorian Calendar
Raise
Analysis
Raise
Analysis
Description
For context, I have posted a question which leaded to a much profound discussion about the representation vs. computational date/time components in our spec and also what's the scope of openEHR in terms of defining date/time types https://discourse.openehr.org/t/dv-date-magnitude-question/2576
Base on the specifics discussed about these method descriptions:
DV_DATE.magnitude()
Numeric value of the date as days since the calendar origin date 0001-01-01.
DV_DATE_TIME.magnitude()
Numeric value of the date/time as seconds since the calendar origin date/time 0001-01-01T00:00:00Z.
Noting that we are only working with the Gregorian Calendar...
"In this specification, all date/time types currently modelled are Gregorian calendar based. This is the same assumption made by ISO 8601, and most technical computing systems today in many parts of the world."
https://specifications.openehr.org/releases/RM/Release-1.1.0/data_types.html#_calendars
... and that Gregorian Calendar came into place on Oct 15th 1582, there is no **historically accurate** way of signalling dates before that by using the Gregorian Calendar ...
"The ISO-8601 calendar system is the modern civil calendar system used today in most of the world. It is equivalent to the proleptic Gregorian calendar system, in which today's rules for leap years are applied for all time. For most applications written today, the ISO-8601 rules are entirely suitable. However, any application that makes use of historical dates, and requires them to be accurate will find the ISO-8601 approach unsuitable. "
https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html
If we are using such origins, introduced by https://openehr.atlassian.net/browse/SPECRM-20 we might need to add a comment about that openEHR uses the proleptic Gregorian Calendar, which is applying the rules of the Gregorian Calendar to dates before Oct 15th 1582.
https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar
That means the leap year rules apply to all years after 0001-01-01 (I believe also before that), that we count the 10 missing days from the Julian to Gregorial calendar switch, and that we don't deal with *accurate* historical dates, we just need that clarification to be able to make the calculations to magnitude() fully consistent.
That also marks a scope for openEHR, meaning that it's not our goal to deal with *accurate* historical dates, which either way will be almost nonexistent in most EHRs.
It is subtle, but this definition/clarification completes a point that could be open to interpretation, generating inconsistencies on different implementations.
For context, I have posted a question which leaded to a much profound discussion about the representation vs. computational date/time components in our spec and also what's the scope of openEHR in terms of defining date/time types https://discourse.openehr.org/t/dv-date-magnitude-question/2576 Base on the specifics discussed about these method descriptions: DV_DATE.magnitude() Numeric value of the date as days since the calendar origin date 0001-01-01. DV_DATE_TIME.magnitude() Numeric value of the date/time as seconds since the calendar origin date/time 0001-01-01T00:00:00Z. Noting that we are only working with the Gregorian Calendar... "In this specification, all date/time types currently modelled are Gregorian calendar based. This is the same assumption made by ISO 8601, and most technical computing systems today in many parts of the world." https://specifications.openehr.org/releases/RM/Release-1.1.0/data_types.html#_calendars ... and that Gregorian Calendar came into place on Oct 15th 1582, there is no **historically accurate** way of signalling dates before that by using the Gregorian Calendar ... "The ISO-8601 calendar system is the modern civil calendar system used today in most of the world. It is equivalent to the proleptic Gregorian calendar system, in which today's rules for leap years are applied for all time. For most applications written today, the ISO-8601 rules are entirely suitable. However, any application that makes use of historical dates, and requires them to be accurate will find the ISO-8601 approach unsuitable. " https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html If we are using such origins, introduced by https://openehr.atlassian.net/browse/SPECRM-20 we might need to add a comment about that openEHR uses the proleptic Gregorian Calendar, which is applying the rules of the Gregorian Calendar to dates before Oct 15th 1582. https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar That means the leap year rules apply to all years after 0001-01-01 (I believe also before that), that we count the 10 missing days from the Julian to Gregorial calendar switch, and that we don't deal with *accurate* historical dates, we just need that clarification to be able to make the calculations to magnitude() fully consistent. That also marks a scope for openEHR, meaning that it's not our goal to deal with *accurate* historical dates, which either way will be almost nonexistent in most EHRs. It is subtle, but this definition/clarification completes a point that could be open to interpretation, generating inconsistencies on different implementations.