On Apr 22, 2005, at 5:01 PM, Martin Hill wrote:
> It seems to me that for *most* practical purposes the ISO-8601 form
> with an assumed UTC is sufficient. As an ignorant layman I thought
> UTC did indeed have a reference point and a timescale... It may not be
> ideal, but it seems the ideal needs a bit more thrashing out.
I agree with the skepticism shown by the quotes around "most". For *many* utility purposes, UTC has indeed been the default, with GMT before that. If there has ever been a default reference location, that has likely been topocentric, i.e., the location at which an observation was made. Thus, even in this rather ad hoc default case, some indication of a reference location would be required. For many purposes it might be sufficient to refer to an observatory DB such as maintained by the IRAF NOAO package.
> If it's not sufficient, can anyone explain (in ignorant laymans terms
> please!) why not? Or obviously just point us at something that does
> so.
UTC has been under attack for several years. The threat of discontinuing leap seconds - while continuing to refer to civil time as "UTC" - would make our prior usage of UTC as an approximation to GMT completely invalid. See Steve Allen's excellent UTC resource page at:
http://www.ucolick.org/~sla/leapsecs
Note that the future of UTC is largely out of our direct control. We may be able to convince the precision timing community to rename civil time something other than UTC, but the question of whether leap seconds will continue to be issued is under the control (it appears) of the International Telecommunications Union. In any event, it would be prudent for VO and astronomy in general to plan for the worst.
> Solar events are based on times rather than spatial positions, and so
> the queries and the result sets need to include these times. These
> are generally UTC timestamps and the solar community know how to deal
> with them in their context
For some utility purposes even a bastardized UTC would be acceptable as a timestamp. UTC will remain monotonic, for instance. (There is good reason to believe there could never be a negative leap second.) One imagines, however, that solar astronomers will care more than most about the relationship of time to the angle of the Earth relative to the Sun. It is this angular information that would be jettisoned with leap seconds. Mean Solar Time would no longer bear any simple relationship to the clock on the wall.
> As a first-step I would suggest UTC of the standard string form, with
> a datatype of 'datetime' (and units as 'UTC' perhaps?); there are
> already plenty of libraries to handle this format for
> simple/primitive/low level operations such as sorting and matching.
> This at least gives us a way of including dates in a VO-standard way
> while we thrash out the deeper problems.
This is similar to FITS DATE-OBS usage and may be acceptable for a range of utility purposes. The general solution (typically required for precise, scientifically useful, purposes) requires something similar in complexity to STC.
Rob Seaman
NOAO
Received on 2005-04-23Z00:58:27