Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] Minor change to DateTime DDLm type

Dear all,

I am the one who originally inquired about the possibility of updating
the existing `timestamp` syntax or introducing a new, less strict time-related
data type.

Firstly, I want to further clarify, that the issue that was cited by James
does not involve tags from the IUCr-curateed dictionaries, but rather
those from the COD-curated DDLm dictionaries, therefore an introduction
of a new data type would probably not require to rework the existing
IUCr dictionaries. I imagine, that most of the date-time data items in
the IUCr dictionaries were defined as such with the intention that they
will mostly be automatically populated by software. The COD tags in
questions, however, are more often populated by human-operators,
and sometimes involves data sources where the full date-time is simply
not available. We would like to be able to both records such partial
timedates and to automatically validate them using a generic validator
(e.g. use a data type that permits recording partial datetimes instead
of artificially padding them with fake minute/second information).
Since DDLm does not currently allow to define custom data types
(I think DDL2 allows that via some regex magic), the only way to
do that properly is through modifying the existing core DDLm types
or adding new ones.

A new data type would allow to retain the strict behaviour of existing
IUCr (and some COD) definitions that use the `DateTime` type while
also allowing for some more flexibility in definitions where this might
be needed.

Sincerely,
Antanas

On Thu, 1 May 2025 at 12:46, Herbert J. Bernstein <yayahjb@gmail.com> wrote:
I think this needs thoughtful discussion.  In these days of computers, it really does not take any extra effort to put in the full and accurate timestamp and there will be times when it matters.  I know people will make mistakes and do things incompletely, but should we encourage them in being sloppy?

On Wed, Apr 30, 2025 at 10:55 PM James H <jamesrhester@gmail.com> wrote:
Dear DDLm group,

The DateTime option for DDLm `_type.contents` encapsulates a date and time according to RFC3339, so something like 1996-12-19T16:39:57-08:00

It seems that sometimes a Date is not enough, but a full time including seconds is too much. CIFs in the wild missing seconds have been encountered by the COD, see https://projects.ibt.lt/repositories/issues/1713. This strictly violates the expected syntax.

The tidiest solution would be to allow minutes and seconds, or just seconds, to be dropped from the timestamp. This would be a slight expansion of the syntax of DateTime in the DDLm `_type.contents` data name, which may have ramifications for software that has been written to expect a full DateTime.

Defining a new type, e.g. `PartialDateTime`, doesn't actually improve the situation because dictionary definitions wanting to adopt the more liberal timestamp would also have to be changed. Defining a new type only makes sense if we are happy to add new definitions to the dictionaries to supersede those that use the old type.

Would this group endorse expanding the acceptable syntaxes of DateTime? See also Github discussion at https://github.com/COMCIFS/cif_core/issues/523.

thanks,
James.
--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________
ddlm-group mailing list
ddlm-group@mailman.iucr.org
https://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group
_______________________________________________
ddlm-group mailing list
ddlm-group@mailman.iucr.org
https://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group


--
Antanas Vaitkus,
Vilnius University,
Life Sciences Center,
Institute of Biotechnology,
room C521, Saulėtekio al. 7,
LT-10257 Vilnius, Lithuania


_______________________________________________
ddlm-group mailing list
ddlm-group@mailman.iucr.org
https://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group

Reply to: [list | sender only]