From: "Mike A'Hearn" To: "Brown, Tyler" CC: Ronald.S.Joyner@jpl.nasa.gov, Joel.Wilf@jpl.nasa.gov, "Henderson, Valerie" , "Raugh, Anne C." , "Grayzeck, Edwin" Date: Thu, 8 Nov 2001 15:13:21 -0500 Subject: UTC & GMT Tyler et al., Anne mentioned some recent discussions about UTC vs. GMT and I thought I should weigh in with an astronomer's viewpoint since there seems to be some confusion about time systems. UTC (Coordinated Universal Time) and GMT (Greenwich Mean Time) are very different from each other both numerically and conceptually. They can differ by up to 0.9 seconds (it used to be 0.7 seconds but I think it was increased to 0.9 recently). UTC is derived from atomic oscillators that run much more uniformly than Earth rotates. UTC has leap seconds (either positive or negative) added on 1 July and/or 1 January to keep it within 0.9 seconds of GMT. These are handled by the famous leap-second kernels in SPICE. GMT is the local hour angle of the mean sun (where the sun would be if Earth's orbit were circular and its obliquity were 0) as measured from Greenwich. Earth's rotation speeds up and slows down seasonally. It also has a strong secular deceleration (dissipation via tides leading to spiraling outward of the moon). It also has unpredicted, small variations. All modern clocks and time systems are based on UTC and, in fact, one does not even know GMT for a given UTC until months after the fact when astronomical observations have been reduced that yield the best value for the small terms in Earth's rotation. No mission would ever use GMT and PDS should never use GMT as the proper time-keeping system, even though the two terms are occasionally and incorrectly used synonymously. Of course, to the nearest second or two, one can't tell the difference between them. Nevertheless, we should never refer to GMT in any official way. Regarding the Z in our time designations. This comes from time zone Z or Zulu (phonetic alphabet for Z). The time zones are labelled consecutively with letters and Z is the label for the time zone centered at Greenwich, so the Z refers to standard time in the Greenwich time zone (which extends in longitude from 7.5 degrees east to 7.5 degrees west) and is NOT adjusted for daylight time (or summer time as they would call it in Europe). Thus Zulu is equivalent to UTC since standard time is based on UTC. On the other hand, this information is redundant and we at SBN never put the Z in our time designations. If there are nodes that use other, random time systems, perhaps the Z is not quite so redundant, but the solution is not to use the Z, but rather to stop using any time system other than UTC (except for spacecraft raw clock counts and for elapsed time, of course). I see no reason for us to be using local time in our data products. Regarding precision. I am not sure what the standards say, but I personally think it is very misleading to quote more digits than are meaningful. Thus I hope that we could truncate times to the nearest hour or even the nearest day, just as we truncate other data to the meaningful number of digits. Mike ----------------------------------------------------------------------- From: Anne Raugh To: Joel.Wilf@jpl.nasa.gov Date: Tue, 04 Nov 2003 12:25:57 -0500 (EST) Subject: Chapter 7 Z/UTC Joel, OK, here's the problem place: Section 7.1. The very first example shows a "Z" on the end of both times and implies that it is, therefore, required (since it is part of the "recognized" formats). Then, in the paragraph below the list of acronym definitions, we have this: The time part of the expression represents time in Universal Time Coordinate (UTC), hence the Z at the end of the expression (see section 7.3.1 for further discussion). Note that in both the PDS catalog files and data product labels the "Z" is optional and is assumed. The paragraph immediately following that also contains a trailing "Z" on the time field and once again implies that the "Z" is required. To recap the problem: o "Z" means the civil time zone at Greenwich. This may or may not be UTC, depending on what year it is and whether you are on land or sea. o UTC is Coordinated Universal Time, and it is the astronomical time standard that should be used for all observation times (like START_TIME). o Because of legacy data, a "Z" found on an observational time field in any older PDS label will be disregarded, and the time will be assumed to be UTC. o New data sets should never use "Z" unless the intent is to indicate specifically the civil time zone at Greenwich, as distinct from UTC. Many thanks! -Anne. ----------------------------------------------------------------------- From: Steven L. Adams [mailto:steven@jpl.nasa.gov] Date: Mon, 10 Nov 2003 13:50:00 -0700 To: Ronald S joyner Subject: Minor change in standards next time revised Ron, I believe the standards need to be changed next time they are revised in section 7.1 "Date/Time Precision". The example listed shows the allowable truncated formats based on the CCYY-MM-DDTHH:MM:SS.sssZ model. What should be added are examples based on the CCYY-DDDTHH:MM:SS.sssZ model. As now exists, a time of PRODUCT_CREATION_TIME = 2003-219 is not acceptable according to the current standards. -Steven ----------------------------------------------------------------------- From: Ronald S joyner To: steven.l.adams@jpl.nasa.gov, steven-adams@sbcglobal.net, Joel Wilf Date: Mon, 10 Nov 2003 14:13:39 -0700 Subject: RE: Minor change in standards next time revised Howdy, You might consider addressing your concern to the Standards person... See Ya, RJ ----------------------------------------------------------------------- From: Sandee Jeffers To: Joel.Wilf@jpl.nasa.gov CC: sjoy@igpp.ucla.edu Date: Thu, 13 May 2004 16:05:23 -0500 Subject: PDSDD formation rule for date/time Joel, The ESA folks (at ESTEC) have developed a tool for verifying and validating PDS archive volumes that we're using (at their request) on our Mars Express data sets before delivering to them and PDS. This tool uses the PDSDD to validate keywords and value formations in the labels. We use the CCYY-DDDTHH:MM:SS.sss date/time formation for our START_TIME and STOP_TIME values in our data labels. The ESA tool rejects this because the formation rule in the PDSDD only has the preferred format of CCYY-MM-DDTHH:MM:SS.sss listed. The PDS Standards Reference sites both formats as accepted, so is there any way to have both formations in the PDSDD? Just wondering... Thanks, Sandee ----------------------------------------------------------------------- From: Joel Wilf To: "J. Steven Hughes" , ron.joyner@jpl.nasa.gov CC: Erin Means Date: Thu, 13 May 2004 19:24:31 -0700 Subject: [Fwd: PDSDD formation rule for date/time] Hi Steve and Ron, We need to make the standards consistent with itself, the data dictionary, and the tools with respect to the acceptable date/time format. In Section 5.4, under "Dates and Times," it says: "Date and time values must be in the PDS standard date/time format: YYYY-MM-DDThh:mm:ss.sss" In Section 7.1, it says: "In the PDS there are two recognized date/time formats: CCYY-MM-DDTHH:MM:SS.sssZ (preferred format) CCYY-MM-DDDTHH:MM:SS.sssZ" At the end of the section, it adds: "PDS standard date/time format, i.e., the preferred date/time format, is "CCYY-MM-DDTHH:MM:SS.sssZ." In Section 7.2.1, it says "Conventional dates are represented in ISO/DIS 8601 format as either... CCYY-MM-DD or as... CCYY-DDD... The former is the preferred format for use in PDS labels and catalog files and is referred to as PDS standard date format, but either format is acceptable." As the attached note indicates, the data dictionary does not list the day-of-year (DDD) version in its formation rules; and apparently the ESA tools don't accept it. (Note: I want to know more about these ESA tools!) This is a mess, and we need a consistent, clearly worded position on dates! Do we accept CCYY-DDD or not? Also, I thought PDS had agreed to drop the "Z" suffix -- re-inforced by the fact we now disallow alternate time zones. What's your answer? -- Joel ----------------------------------------------------------------------- From: Joel Wilf To: Joel Wilf CC: "J. Steven Hughes" , ron.joyner@jpl.nasa.gov, Erin Means Date: Fri, 14 May 2004 08:33:21 -0700 Subject: Re: [Fwd: PDSDD formation rule for date/time] Hi Steve and Ron, I forgot to include my preference in the time format issue. I think we should say clearly that there are two acceptable formats for date/times: CCYY-MM-DDTHH:MM:SS.sss CCYY-MM-DDDTHH:MM:SS.sss There is no trailing "Z", and the tools should issue a warning that use of a trailing "Z" has been deprecated. -- Joel ----------------------------------------------------------------------- From: Joel Wilf To: sjeffers@swri.org CC: sjoy@igpp.ucla.edu Date: Fri, 14 May 2004 08:57:33 -0700 Subject: Re: PDSDD formation rule for date/time Hi Sandee, > The ESA folks (at ESTEC) have developed a tool > for verifying and validating PDS archive volumes > that we're using (at their request) on our Mars > Express data sets before delivering to them and > PDS. > I haven't seen the ESA tool, so I can't vouch for how well it adheres to PDS standards. > This tool uses the PDSDD to validate keywords > and value formations in the labels. We use the > CCYY-DDDTHH:MM:SS.sss date/time formation for our > START_TIME and STOP_TIME values in our data labels. > The ESA tool rejects this because the formation rule > in the PDSDD only has the preferred format of > CCYY-MM-DDTHH:MM:SS.sss listed. The PDS Standards > Reference sites both formats as accepted, so is > there any way to have both formations in the PDSDD? > > I agree with you that the day-of-year formation of START_TIME and STOP_TIME should also be given in the description in the data dictionary. However, I don't see how the ESA tools could use this description to enforce the date/time formation rules. Enforcement of the date/time representation is actually a function of the ODL grammer (remember ODL is the language that labels are written in). The ODL grammer is described in Chapter 12 of the Standards, and if you look at Section 12.3.2.4, you will see that "Dates can be represented in two formats: as year and day of year; as as year, month and day of month." The Standards show the actual grammatical production rules -- the statements with the ::= characters in them -- and if that grammer is properly used in an ODL parser, then at the language level, your representation of dates will be accepted. As mentioned above, I haven't seen the ESA tools, so I'm not sure how they parse ODL and do additional validation checks. -- Joel -----------------------------------------------------------------------