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