What are the limits for the Date sort value?

Help
1

A user on Reddit r/gramps is trying to create a timeline of a fictional world.
They are having problems with sorting Dates in the extreme prehistory.

See chronological date events in the BC era

What are the hard limits (in Years) for Date dateval and sortval sorting? How many years into the past (and into the future) can Gramps effectively index?

image

It wasn’t effective to auto-sort when date are entered as text either. (Tried using leading zero with + and - without success too.)

Here’s some sample dates that would not auto-sort correctly:

+100000.03.23
-100000.09.13
-010000.05.19

Test Events in the user’s fictional world:

image
image1080×580 129 KB

2

Correct me on the following assumptions by perplexity.ai when looking at the following code:

Does it mean the possible date range is calculated from a zero at the Unix epoch of January 1, 1970.

Which gives a possible Date range of:

  • Earliest: December 31, 99999 BCE (represented as -99991231)
  • Latest: September 9, 99999 CE (represented as 999990909)

Perplexity’s estimations seems wrong. It looks like it is interpreting it as “YYYYYMMDD” (Where the YYYYY is MyriadMillenniumCenturyDecadeYear) Shouldn’t it be ±999,999,999 days from 1 Jan 1970? Or:

  • Earliest: Circa 2,735,880 BCE (represented as -999999999)
  • Latest: Circa 2,739,820 CE (represented as 999999999)

And it looks like the Latest valid date is actually limited to today() plus 1 year rather than the

3

All dates in Gramps are internally converted to a modified Julian day number (called in Gramps SDN = serial day number). Consequently, the calendar starts on Jan 1, 4713 BC (proleptic Julian calendar) or Nov 24, 4714 BC (proleptic Gregorian calendar) for a period of 7980 years.

“Proleptic” means a year 0 is introduced to ease computation. Therefore BC years are offset by 1 in this calendar.

The modification intends to provide convergence with common interpretation of “day”. With SDN, a day starts at midnight 00:00 while it starts at noon 12:00 with Julian (where some event occurring in the morning has a different day number than an event in the evening of the same “day”).

Computations are located in gramps/gen/lib/gcalendar.py. I have not checked what happens if a negative SDN is presented to the converters, nor with an SDN exceeding the 7980 years period.

This Reddit user should look at the functions in the aforementioned file to see what needs to be patched to cope with an extended period.

Note: there is a trick there to facilitate conversions. Year origin is temporarily shifted to March 1 to make month sequences more regular and have the leap day at end of the “year”.

2 Likes
4

There was an earlier thread about posting B.C.E. dates.

The key was putting a negative number in the date editor.

I did an additional test using the year -100000000000. The resulting entry was 9999 B.C.E. Obviously, there is a limit.

With another entry 6666 B.C.E. (entered with the date editor) and then the events sorted by date, 6666 B.C.E. was sorted first before 9999 B.C.E.

5

This may be a consequence of truncation or other integer arithmetic peculiarities during computation of SDN.

Dates are supposed to be inside the first Julian Period (the first 7980 years starting in 4713 BC), for an SDN between 1 and the upper limit.

Submitting dates outside this interval yields undefined results. The code does not check the interval bounds. These dates are out of spec and anteriority is not guaranteed.

For Gregorian dates, the code add 4801 to the year so that all years numbers in the Period are positive. Submitting 6666 BC or 9999 BC results in a negative year. This offset year is then used in mod 100 and integer division by 100. I don’t think integer division is a problem because there is a single way to do it with negative numbers. However mod can mathematically be defined four ways with negative numbers (two ways if the divisor is restricted to positive, as is the case with 100).

I’ll bet that the “naive” mod with positive remainder for negative dividend is responsible for the inconsistent result. I didn’t check Python mod implementation regarding this mathematical subtlety. The “secular” remainder for year is multiplied by 1461 and this can dramatically change the SDN in the “wrong” direction.

1 Like
6

We use the sortval field to store the SDN. For sorting in the GUI, we convert this into a nine digit string which is sorted alphabetically. This explains the problems when the SDN is negative.

The python datetime module which we use to find the weekday for the date displayer is only valid for the years 1 to 9999.

Otherwise extreme dates could probably be made to work.

1 Like
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.