Clarification on Date precission fields and their use

Get Help
1

Hello!

There are several date fields on specify schema. Giving a working example, in CO we use catalogedDate and custom date1 fields to save the record creation date and real creation date of a collection object.

Both fields are partialdateui plugin with uifieldfomatter=date and their inicialization are:

initialize=“name=PartialDateUI;df=catalogedDate;tp=catalogedDatePrecision”
initialize=“name=PartialDateUI;df=date1;tp=date1Precision”

tp’s date1precission and catalogeddateprecission exists on database schema.

If you insert one value as “year month” and a s and date1 value as dd/mm/yyyy or as yyyy value, when you access to the collection object detail, you have the plugin setup automatically on that kind of data saved.

How specify7 does that?

By the other hand, we placed the dateui plugin at accession form, using dateaccessioned and datereceived fields, but without the tp (precission) field due we cant find the precision hidden fields on the accession table schema. When you create an accession and introduce one of those dates, doesnt matter which kind of style you place (full date, month/year or year: When you edit or view the data in the edit/view form, you always get the dd/mm/yyyy full date.

So: Its the precision field saving this value? if it is, why doesnt exists a precision field for all date fields?, Its possible to tweak this in any way?

S!

1 Like
2

Hi @miquelmAuupa,

There are two types of date fields used on forms:

  1. Precision date fields where the uitype="plugin" and database schema field type is calendar/byte.
    image

  2. Full date fields where the uitype="formattedtext" or uitype="text" and database schema field type is calendar.
    image

The catalogedDate and date1 fields on the Collection Object table are calendar/byte field types defined as uitype="plugin" in the XML.

The plugin uitype supports the partialDateUI plugin, which allows for date precision to be set on the form. Each field of this type actually has two fields in the schema, one calendar and one byte. For example, date1 is calendar but is accompanied by date1precision which is a byte field type in the table’s schema field list. This is why we use tp=date1Precision initialization in the XML.

Expand for details on plugin fields for providing partial dates

Attributes:

  • default (string, optional)
  • initialize (string, optional)
    • df (string, optional) – Stands for “Date Field”
    • tp (string, optional) – Stands for “Type Precision”
    • defaultPrecision (‘year’ | ‘month-year’ | ‘full’, optional, default: ‘full’)
    • canChangePrecision (true | false, optional, default: false for read-only fields and when in form table; otherwise true)

The dateAccessioned and dateReceived fields on the Accession table are calendar field types defined as uitype="formattedtext" or uitype="text" in the XML. These fields are the more commonly available date field in the schema for a given table.

Fields with these uitypes do not support date precision as they cannot be configured with the partialDateUI plugin in the XML because they lack compatibility with the plugin uitype. This is why you are unable to display a date format other than full date using the fields you mention.

Thank you for reaching out!

– Bronwyn

3

Thank you.

Totatlly Clear. So only those calendar fields with a pair calendar/byte are allowed to use the partialdateui (in fact, both can use it, but if they have no byte field attached to the calendar field, the status of the entry is lost and always show dd/mm/yyyy date after insert information.

Maybe in the future, it would be awesome to be allowed to select any date on this format, even the custom date fields. I guess there is no plan to doit in the current roadmap, isnt it?

Best regards!

1 Like
4

I think that sounds like a great feature request!

While I could not find any existing requests to expand support for partial date fields on forms, I always encourage submitting a post here on the forum in the New Feature Requests category describing your need and use for this addition. There, Specify users can show their support and discuss use cases in their database to inform its inclusion in our development timeline.

Let me know if you have any further questions :slight_smile: