search

FamilySearch / GEDCOM

Apache License 2.0
170 stars 22 forks source link

how to export TIME payload which does not match the 24h format #168

Open albertemmerich opened 2 years ago

albertemmerich commented 2 years ago

GEDCOM-L group discusses how to export a payload for a time not matching the 24h format defined in 7.0.

example: BIRT on 12 SEP 1888 "early in the morning"

GEDCOM 7.0 has no TIME.PHRASE to do it. We see two possibilities:

2 DATE 12 SEP 1888
3 PHRASE early in the morning
2 DATE 12 SEP 1888
3 TIME
4 _PHRASE early in the morning

Both versions are not perfect: the first one does not match to applications which have separate data fields for DATE.PHRASE and TIME._PHRASE, the second one will often result in loss of data at transfer.

We would like to see a recommendation for GEDCOM 7.0 in the FAQ, and a solution within standard for coming versions 7.x

dthaler commented 2 years ago

Discussion 7/12/2022:

First example above is perfectly fine. (The second example in cannot be used as is since TIME requires a payload.)

One could however do:

2 DATE 12 SEP 1888 3 _TIME 4 PHRASE early in the morning

but it will be interpreted by fewer programs, so is not as good as the first one.

For 7.1, we should consider adding TIME.PHRASE

tychonievich commented 2 years ago

Question: Right now we use the same structure (g7:TIME) for the TIME under both g7:DATE-exact and g7:DATE, but g7:DATE-exact does not have a PHRASE. We also define the substructures of a structure to depend only on its structure type. Thus, should we

I feel like there should be a fourth option, one that adds TIME.PHRASE only where needed in 7.1, but I haven't come up with it yet.

Norwegian-Sardines commented 2 years ago

Where TIMEDATE.PHRASE would be used for “Born in the morning of the one year anniversary of his parents”. An exact quote for my family!
Where DATE.PHRASE would be used for a phrase: “Born at 5am on the one year anniversary of his parents” Where TIME.PHRASE would be used for an exact or given calendar date, but including a “in the morning” phrase. “Born in the morning of Christmas Day”.

I suppose TIMEDATE.PHRASE could be redundant if a DATE and TIME values were concatenated together.

albertemmerich commented 2 years ago

I missed the point, that g7:DATE-exact does not allow a PHRASE, as was pointed out by Luther. Let us see this from user's point of view, working with a version offering DATE, TIME, and DATE.PHRASE (no other standard tags possible so far...). I am quite sure,

2 DATE 12 SEP 1888
3 PHRASE early in the morning

will be user's solution as he cannot fill in a TIME. Do we really want to tell the user, that because an exact DATE may not have a PHRASE, he is not allowed to do that? Coming to artificial "solutions" like

2 DATE SEP 1888
3 PHRASE early in the morning (on 12th SEP)

???

Next point: Why don't we allow DATE-exact.PHRASE. If there is any difficulty to interpret a date recorded, I could add the original version shown in the record in DATE.PHRASE and my interpretation of it in DATE-exact, if the interpretation is an exact date. If it is not, I am allowed to do so. Makes no sense to the user that if he interprets it as an exact DATE he no longer can use it! Theory is we can see the original text in the SOUR under the same event/fact as DATE is. Ok - but there we find the whole text for the event, and not an extract for DATE. We do not have DATE.SOUR in the standard, so I disagree to put the orginal text in source citation is a good idea. We do not have DATE.NOTE, so it is neither a good idea to put it into a NOTE. The information should clearly be related to DATE!

So, if I want to have a standard conforming export, I have to use DATE-exact._PHRASE. And as Dave pointed out, for my "early in the morning" I need DATE._TIME.PHRASE. It is time to repair this nonsense in the standard!

My favorite is: DATE DATE.PHRASE TIME TIME.PHRASE for alle DATE payloads (including empty and exact ones) and all TIME payloads (again including empty and exact ones).

tychonievich commented 2 years ago

g7:DATE-exact is only used in places where we expected computer-generated timestamps, and where date phrases and approximate dates do not make sense:

In all of these cases, a date or time phrase does not make sense. If the user interface allows a phrase to be entered here, I would argue that it is violating the intended semantics of these structures.

dthaler commented 2 years ago

g7:DATE-exact is only used in places where we expected computer-generated timestamps, and where date phrases and approximate dates do not make sense:

  • HEAD.SOUR.DATA.DATE -- the last-update timestamp of the database this file was extracted from
  • CREA.DATE and CHAN.`DATE -- the timestamp when a record was first created/last modified (respectively)
  • LDS Ordinance.STAT.DATE -- the date of an ordinance as recorded in the Church of Jesus Christ of Latter-Day Saints' internal records (not to be confused with LDS Ordinance.DATE which is used for dates from the user instead of from the church)

In all of these cases, a date or time phrase does not make sense. If the user interface allows a phrase to be entered here, I would argue that it is violating the intended semantics of these structures.

I'm not sure I agree. Or rather I would only agree with the above if a breaking change is made that we could not make until 8.0. I do on the other hand agree with @Norwegian-Sardines's statement

I think a “minor” update for g7:TIME to have a g7:PHRASE is appropriate for DATE-exact because the definition is for an exact date, not exact date/time.

Specifically for me the issue is that DATE-exact with a TIME does not require the TIME to be in UTC but is permitted to be in what the GEDCOM spec calls "event-local time". Asserting that approximate times do not make sense for computer-generated timestamps is true in theory but does not match the GEDCOM reality of permitting event-local time for generated timestamps in my view, since they cannot be converted to UTC which is the only real exact time since DATE-exact has no location from which one can determine what is "event-local". As such any DATE-exact in event-local time is by definition (at least in my mind) not an exact time, but rather a statement that could be any time (zone) during that date, and even the DATE is approximate (plus or minus a day) since when an event-local time is converted to UTC, it may result in a DATE change.

The only way to make a DATE-exact actually be exact, in my view, would be require UTC for DATE-exact, which is what I think we should do in 8.0. But it does mean that for event-local times, a phrase could be used for time zone in theory (since we don't permit a time zone other than Z in TIME).

At minimum I think we should recommend against using event-local time with DATE-exact in the current spec.

Norwegian-Sardines commented 2 years ago

DATE-exact is only used is

g7:DATE-exact is only used in places where we expected computer-generated timestamps, and where date phrases and approximate dates do not make sense:

  • HEAD.SOUR.DATA.DATE -- the last-update timestamp of the database this file was extracted from
  • CREA.DATE and CHAN.`DATE -- the timestamp when a record was first created/last modified (respectively)
  • LDS Ordinance.STAT.DATE -- the date of an ordinance as recorded in the Church of Jesus Christ of Latter-Day Saints' internal records (not to be confused with LDS Ordinance.DATE which is used for dates from the user instead of from the church)

In all of these cases, a date or time phrase does not make sense. If the user interface allows a phrase to be entered here, I would argue that it is violating the intended semantics of these structures.

Sorry I understood DATE-exact to be an exact date used in EVENT.DATE (DateValue)!

DATE-exact inherits is format from DateExact which does not include a TIME (exact or otherwise). EVENT.DATE does not use DateExact it uses DateValue and includes the following options: DateValue = date / DatePeriod / dateRange / dateApprox / ""

So their should be a g7:TIME-exact for time stamps and a g7:TIME (TimeValue) for all other uses, and a TIME.PHRASE subordinate to it.

tychonievich commented 2 years ago

Trying to summarize:

Please correct me if I've misrepresented any views. Others' views are also welcome.

Based on this, it seems like putting TIME.PHRASE in 7.1 is the compromise path forward, with a separate g7:TIME-exact to be considered in 8.0. I've drafted a 7.1 PR #230, including a recommendation for future compatibility with TIME-exact and hopefully minimize any disruption the anticipated 8.0 change will cause.

dthaler commented 2 years ago

I also advocated for a 7.0 PR with a recommendation, which I can author for review.