Should SDATE be more limited?

[tychonievich]

I received the following question and proposal from a GEDCOM tool builder in my personal email and thought it worth sharing here. I am not personally endorsing the idea (I have no direct interest in it either way), just sharing it to see what others think.

SDATE stores a date for sorting. To sort a date I only need a "date".

7.0.x defines:

n SDATE <DateValue>

and

DateValue   = date / DatePeriod / dateRange / dateApprox / ""
date        = [calendar D] [[day D] month D] year [D epoch]

<DateValue> includes DatePeriod, dateRange and dateApprox, where I don't see any need. The only requirement for sorting is "date". ABT, FROM, CAL, ... should have no impact of sorting and a FROM/TO and BET/AND makes no sense.

Therefor I suggest to change the specification in the future to

n SDATE <date>

[fisharebest]

Makes perfect sense. You cannot easily sort date ranges.

e.g. does 12 JUN 2000 come before or after BET 01 JUN 2000 AND 30 JUN 2000

[radev8]

For that example |12 JUN 2000| is neither before or after |JUN 2000 so you would have to leave the order as is because either order is correct.  If you are sorting items in an existing list then they should remain in the current order.  If the list is a new list such as creating a timeline of multiple dates then the order is at the discretion of the developer.| |||JUN 2000 is effectively a date range from 1 |||||JUN 2000 to |||||30 |||||JUN 2000. |||| |Date ranges on a sort-able date are not helpful for creating a list where there is only one possible correct result| |||||I would suggest|||||||||||||that the 'date' should not have optional day and month and be defined as||||||| | |n SDATE <sdate>| || |sdate = [calendar D] day month year [D epoch]| |||||||||||| |This would ensure consistent sorting of dates where the SDATE is provided for DATE values with ranges.| | | ||

…

On 5/05/2022 4:11 am, Greg Roach wrote: Makes perfect sense. You cannot easily sort date ranges. e.g. does |12 JUN 2000| come before or after |JUN 2000| — Reply to this email directly, view it on GitHub <#140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6C42PKWDR2ZIZNAPTR2X3VIK4TTANCNFSM5VCXB7FA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tychonievich]

It seems like both of you are proposing that SDATEs should provide a single unambiguous ordering rather than the current partial order provided by DateValue. If I am understanding that correctly, I assume calendars are also problematic as sorting dates in different calendar systems requires extra program knowledge? If that's true, would the easiest proposal be that the payload of SDATE would be DateExact? As a reminder, DateExact is defined in the current spec as

DateExact   = day D month D year  ; in Gregorian calendar

[fisharebest]

Users of my application tell me they just want to sort facts/events (usually undated ones).

An exact sort-date is one way to do this. Although it is an indirect way of achieving the desired result.

[radev8]

I would agree that the best proposal is that the payload of |SDATE| would be |DateExact | This does seem the best way to have the SDATE field achieve it's intended purpose of having a sort-able version of a date .

…

On 6/05/2022 1:07 am, Greg Roach wrote: Users of my application tell me they just want to sort facts/events (usually undated ones). An exact sort-date is one way to do this. Although it is an indirect way of achieving the desired result. — Reply to this email directly, view it on GitHub <#140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6C42PQA43T7FITXTEQNTTVIPPZXANCNFSM5VCXB7FA>. You are receiving this because you commented.Message ID: ***@***.***>

[albertemmerich]

I disagree to the proposal to only allow DateExact as payload of SDATE.

For me the most often seen use case is sorting by only showing a year as payload of SDATE, like
2 SDATE 1887
That is sufficient for marriages, children, and general in most cases for individuals to give an ordering by birth or marriage, which is done this way by my application.

If you sort events by SDATE then we have to discuss whether we allow DATE.TIME, too.

I think the minimum we should allow in SDATE is: [[day D] month D] year [D epoch]
There is no definition for that so far in 7.0, as date includes the optional [calendar D], and I agree to sort by calendar dates the application has to interpret all calendars used. So we need without [calendar D]. Moreover DateExact would exclude all BCE cases, I think we should allow these.

And I want to point out, that any restriction to SDATE would make valid 7.0 files no longer valid. i.e. this is a major modification not possible in 7.x.

[radev8]

The backwards compatibility and exclusion of BCE dates are strong arguments for not using EXACTDATE and the current minimum of including the year does help the achieve the common use case of sorting children. I agree that the most appropriate recommendation is SDATE: [[day D] month D] year [D epoch]

…

On 17/05/2022 12:28 am, Albert Emmerich wrote: I disagree to the proposal to only allow DateExact as payload of SDATE. For me the most often seen use case is sorting by only showing a year as payload of SDATE, like 2 SDATE 1887 That is sufficient for marriages, children, and general in most cases for individuals to give an ordering by birth or marriage, which is done this way by my application. If you sort events by SDATE then we have to discuss whether we allow DATE.TIME, too. I think the minimum we should allow in SDATE is: [[day D] month D] year [D epoch] There is no definition for that so far in 7.0, as date includes the optional [calendar D], and I agree to sort by calendar dates the application has to interpret all calendars used. So we need without [calendar D]. Moreover DateExact would exclude all BCE cases, I think we should allow these. And I want to point out, that any restriction to SDATE would make valid 7.0 files no longer valid. i.e. this is a major modification not possible in 7.x. — Reply to this email directly, view it on GitHub <#140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6C42JUXWFNUWDEU5LBUGTVKJLPNANCNFSM5VCXB7FA>. You are receiving this because you commented.Message ID: ***@***.***>

[dthaler]

Maybe say something like:

Note: it is recommended to use a payload that matches [[day D] month D] year [D epoch]. Other DateValue forms may have unreliable effects on sorting, and may not be supported by future versions of the FamilySearch GEDCOM specification.

That said, it doesn't make sorting completely deterministic since it doesn't define the order between 15 JUL 1900 vs JUL 1900 vs 1900, for example. So the fact that 15 JUL 1900 vs "BET 1 JUL 1900 AND 31 JUL 1900" vs "BET 1 JAN 1900 AND 31 DEC 1900" is unpredictable across implementations is just a different instantiation of the same problem.