Discussion List Archives

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

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

I am lost.  I thought we were talking about the specific CIF data items in a crystallographic data collection
making the date/time as which each particular data frame was collected, which when we last defined it
was

CIF Date and Time

Many CIF data items take as value a date or a date and time (e.g. _audit_creation_date) or may include a date/time string as part of their expected content (e.g. _audit_update_record). The convention for expressing a date/time string is as follows, and is consistent with the ISO standard ISO 8601:1988(E). A unique instant in time may be defined by concatenating
  • a date string in the format YYYY-MM-DD, where YYYY represents the year number in the Occidental Gregorian calendar, MM is the (zero-padded) month number, and DD is the (zero-padded) day number
and optionally
  • the character "T" followed by a time in the 24-hour clock format hh:mm:ss, where hh, mm and ss are respectively the hour, minute and second, zero-padded as necessary
  • a plus or minus character, corresponding to time zone offsets respectively east and west of Greenwich, followed by the offset value in the format hh:mm (representing hours and minutes difference from Coordinated Universal Time)
Depending on the required precision of the date/time, the full string may be truncated from the right as appropriate.

Examples

1997-08-12T13:55:58-05:00
Four minutes and two seconds before two o'clock on the afternoon of 12 August 1997, at the latitude of Hamilton, Ontario (corresponding to supper time at Greenwich).
1997-08-12T13:55:58+05:45
Four minutes and two seconds before two o'clock on the afternoon of 12 August 1997, at the latitude of Kathmandu, Nepal
1997-08-12T13:55:58
Four minutes and two seconds before two o'clock on the afternoon of 12 August 1997, local time
1997-08-12T13:55
Five minutes to two, afternoon of 12 August 1997
1997-08-12
12 August 1997
Updated 12 August 1997

Copyright © 1997 International Union of Crystallography

IUCr Webmaster
========================================================================================================

Certainly if you are going to define the time for a cup of coffee you need much less precision than you need
to keep thousands of frames what were collected in a modest number of seconds in the correct order.  In
that case I believe it is both bad science and a very bad idea to record times to a low precision that may
jumble the order in which the frames were collected and mess up, say, radiation damage studies.  I believe
the current DDL2 definition is in this case, clear, accurate, and appropriate to the use proposed.  If you are
proposing something else, please state precisely what you are proposing to change to what with examples
that are appropriate to the use being discussed.

Notice the wording "Depending on the required precision of the date/time, the full string may be 
truncated from the right as appropriate."  Isn't that good enough to fit your coffee use case?  
For actual data collection, we may choose to specify the su or ESD, but with frame rates now headed higher 
and higher, I think encouraging imprecision in datetime stamps is a big mistake and we should use
whatever precision is available to us at each beamline.  The question is not one of elegance, but of
practical utility.
_______________________________________________
ddlm-group mailing list
ddlm-group@mailman.iucr.org
https://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group

Reply to: [list | sender only]