An entity lost its time after an edit

​

Signs

• penumbra context entity <entity-id> --json shows a time whose revision is lower than the entity’s entity.revision, or shows no time.
• An extracted item showed valid_time or due_time in penumbra graph workspace show "<workspace>" --json, and it shows none after you edited the item.
• An edit of a new item in a workspace is refused with extraction_time_context_unavailable.

​

Why it happens

An extraction writes three times on each item: a valid time, a due date and a source time. A submit settles them for the revision that it creates. A time belongs to that one revision. Penumbra does not carry a time to a later revision, so an edit gives the entity a new revision with no time. In a workspace, an edit of the type or the properties of an extracted item reads its date properties again. The item keeps a valid time or a due date only if an edited date property reads as a date.

​

What Penumbra does

By itself:

• Settles the valid time, the due date and the source time of an item for the revision that its submit creates. No later revision gets them.
• Shows the latest time that exists for an entity, with the revision that it belongs to. A later revision then shows an older revision’s time.
• Reads the date properties of an extracted item again when you edit its type or properties in a workspace. It drops the old valid time and due date first.
• Keeps a new valid time or due date only when an edited date property reads as a date. A missing or unreadable value removes the time.
• Keeps the source time of an extracted item through an edit.
• Writes no time for an item that updates an existing entity. Only a new item carries its time into the submit.
• Refuses the edit of an extracted item with extraction_time_context_unavailable when it cannot check how the extraction read its dates.

You must:

• Compare time.revision with the entity’s revision before you say that a date is current.
• Send every property, the date property included, when you edit a new item in a workspace.
• Tell the person when an edit left the entity without a time of its own.

Not handled:

• Nothing carries a time to a later revision of an entity.
• No command sets the valid time, the due date or the source time of an entity.

​

Do

1. Read the entity: penumbra context entity <entity-id> --json. Compare time.revision with entity.revision. If they differ, or no time is there, the current revision has no time of its own.
2. Tell the person which revision the date belongs to. Do not call it the date of the current revision.
3. Before you edit a new item in a workspace, note its valid_time and due_time in penumbra graph workspace show "<workspace>" --json. Send every property with the edit, and write each date as a date. Read the item again. If a time is gone, correct the date property and edit again.
4. If the date matters to the answer, give the date that the cited passage or its File version states. Say where it comes from (card rule file.4, problem file-has-no-source-date).
5. After a submit that updated an existing entity, read time again. Do not promise the person that the update added a date.

​

Don’t

• Don’t tell the person that an edit kept the dates of the entity.
• Don’t edit only one property of a new item and expect the others to stay (card rule entity.2).
• Don’t extract again only to put a date on an entity that exists. An item that updates it writes no time, so read time after the submit.

​

Check

• You compared time.revision with entity.revision, and you told the person what the numbers show.
• A new item you edited still shows the valid_time and due_time that it should have.

​

Related

Card entity, with rule entity.2. Card file, with rule file.4. Card citations-to-confirm. Card extraction, with rule extraction.9. Problem file-has-no-source-date.

​

Keep going

Entity · Workspace · Extraction · File · A File has no source date · Citations to confirm