- The ASTM E57.04 Data Interop subcommittee is debating how to specify DateTime in the standard.
- There are 3 options being discussed.
- One of the key issues involves the conversion from GPS time to other time standards due to “leap seconds”.
We are having quite a debate within the ASTM E57.04 Data Interoperability subcommittee on the importance of time. If you have never been involved with creating a standard, it really is a learning experience. Maybe we can get a few of you to provide your thoughts, in case we are missing something.
Basically the key issue is how important is it to accurately specify the time of a scan. Remember that we are trying to have the standard apply as broadly as possible, including mobile mapping and airborne LiDAR platforms, while at the same time trying to keep things simple.
We have one camp that maintains that DateTime should be specified as year, month, day, hour, minute, second – YMDHMS with it left up the user to be responsible for choosing whether it is UTC, TAI or GPS time. An optional field would be available to indicate what time standard was being used. This is the single format, multiple time references – Option #1.
GPS time is specified as GPSweek/GPSsecond. The issue with using it is that the GPSweek rolls over periodically and there is an issue with leap seconds that are added as needed, but GPS time can be specified with high relative precision.
The second proposal is to allow either YMDHMS or GPSweek/GPSsecond to be explicitly used. That is, the standard would support both formats rather than just YMDHMS as in Option #1.
A third proposal is also on the table to use GPSweek/GPSsecond as the only allowed format. This is the method used in the LAS standard. The standard would provide code to convert from GPS time to any other universally accepted time standard. This would support those who need the highest precision, and with a bit of work, could also be converted to a different time standard. The objection to this is the issue of leap seconds, since the conversion software will have to be updated each time a leap second is published.
See the fun you are missing. Your thoughts would be appreciated.
This post was written by Gene V. Roe
I am surprised that you haven’t looked at ISO 8601 and all the related IETF specifications on reporting and reconciling date-time. The same problems arise on the Internet at various levels and even in productivity software (e.g., the ODF and OOXML formats).
I believe there are various pitches on how to deal with leap seconds too, although astronomers and aerospace folks may be a better source if to-the-second time-interval determinations are significant.
Thanks for the info.
Gene
It is not possible to be accurate (to the nanosecond), broad, and simple.
Time is not something that can be known, it must be measured by someone and then provided to something. It’s a process, and it’s a process which always has lookup tables.
In order to agree on time (within the bounds that relativity allows, and for moving detectors that may be relevant to consider as well) it must be obtained from a known source which is comparing itself with other known sources and publishing ex post facto tables of corrections to the time which it was providing.
There is no source for TAI, it is not available until next month, and BIPM itself will recommend not using it.
UTC is available, but its definition is subject to an international committee who are not in consensus about whether it should change its characteristics. Whether or not UTC has leap seconds in the future, it has already had them, so they must be addressed. Also, UTC from one source is not the same as UTC from another source, thus the BIPM publishes Circular T every month, a table of differences which must be applied.
GPS time is under the control of US DoD, USNO, and (even though it is unlikely to change its characteristics at the microsecond level) as such is not palatable for international standards committees. At the microsecond level it is effectively the same as TAI, but at the nanosecond level there are, as with all time scales, lookup tables which must be applied to get agreement. Beyond that, the quality of the individual GPS receivers varies considerably at the sub-microsecond level, and nanosecond precision might require documenting the hardware and software in use during a measurement.
This is an engineering decision which has to conform itself to the available (and subject to change) standards and services. Good luck.
Thanks for the perspective.
Gene