|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
[fitsbits] Draft WCS Paper V: Time
Howdy,
On Apr 2, 2009, at 2:57 PM, Arnold Rots wrote: FITS WCS Paper V: Time ====================== Draft is available for comment ------------------------------ I have the pleasure, on behalf of the team of authors, of (finally) announcing the draft of WCS Paper V on Time coordinates. Good draft. This version still needs some polishing and there are a few issues that are yet to be resolved. You will notiice editorial comments printed in red. The major polishing needed is 1) sorting out section 5, and 2) perhaps more prescriptive usage related to tables 3, 4 & 5. I like the reference to Gregorius, 1582. The VOEvent standard references Tycho, 1573. The intent is that this discussion be carried on through even though this announcement also goes out on fitsbits. I'm replying to both since I'm not sure I'm on fitswcs. Somebody want to provide a pointer to joining that list? Comments: 1) The meaning of "time stamp" encompasses both astronomical epochs (instants of time) and civil calendar dates. For example, today is 2009-04-06. This isn't just an epoch approximate to a 24 hour period, but rather is a boolean assertion. This matters logistically because 1) a single HDU may have civil dates in UTC (for instance) but a different TIMESYS, and 2) expressing DATE or DATE-OBS in the limited CCYY-MM-DD form doesn't actually specify a date, but rather an epoch. Other keywords (for instance, NOAO's DTCALDAT) are explicitly a calendar date - meaning a calendar date for a particular locale. It is likely unworkable to require some specification like "TOPOCENT" merely to indicate that a variety of keywords expressing calendar dates are relative to the local timezone. 2) Usage of DATE-OBS prior to Y2K only permitted expressing a date. In many instances DATE-OBS is still only used to express a date. Another keyword such as "UT" or "TIME-OBS" is used to express the other part of the observation epoch. One could wish it otherwise, but that is how the keyword is used. The paper should address this situation. The first point being that DATE-OBS and TIME-OBS should correspond to a single atomic instant. In reality the calendar and the clock often tick over separately at midnight (UT) resulting in HDUs with spurious time stamps. 3) Time often means "phase". Does the paper need to delve into time series usage for (for instance) variable star light curves? Another expression of phase is a 24 hour clock. The subset ISO-8601 datetime string allows the time to be optional, but not the date. And yet FITS headers often express times without dates (many times corresponding to angles), and these are often sexagesimal just as with ISO-8601. 4) Section 3, second sentence - missing period. 5) Section 3.1.1, 1st paragraph, final sentence - "will will". 6) Section 3.1.1, 3rd para, 1st bullet - the discussion of the Gregorian calendar may want to include a reference to the old-style/ new-style confusion in the English speaking world. 7) Section 3.1.3 - says "In headers, the value may be written to as many significant figures as required." This is constrained by the 70 (depending how you count) character limit for keyword values. 8) Table 1 - mixes deprecated and obsolete options with recommended time scales. Since the list is not alphabetical, there must be some implied hierarchy. Recommend placing the desirable choices at the top and the inappropriate choices at the bottom of the list. Perhaps the list should be partitioned between those time scales FITS recommends and those we must tolerate? 9) Section 3.4 - Perhaps a discussion of what the unit of the "second" means? All the others derive from this (in the paper), but this is of course a polite (?) fiction. If a second for FITS is an SI second, then a day for FITS has nothing to do with the rotation of the Earth. I don't believe such a consensus exists (but please point me to it, if so). I'm not trying to relive the leap second wars, but you can't avoid the issue by not discussing your definitions. Perhaps there is some reference that can be pointed to so the issue can be transferred elsewhere? If the intent is to leave "second" undefined in principle, the document should clearly state this. If the thought is that the answer is implicit in the time scale, I don't believe that to be the case. A day is not simply a unit equivalent to 86400 seconds. Whether all years in widespread FITS usage are really Julian is another such question. 10) Section 3.6 - is XPOSURE coining new FITS usage? Many observatories I'm familiar with use EXPTIME. I'm not sure what to make of phrasing like "or equivalent" and "or a similar keyword". The paper should be very explicit what is required. Note a complication for instruments that can create multiple data products for a single exposure - often such a camera will allow a subexposure at a particular wavelength to be shorter than the others. What does paper V advise here? Using the same keyword in separate HDUs or using separate keywords? Rob |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[fitsbits] Draft WCS Paper V: Time | Arnold Rots | FITS | 0 | April 2nd 09 10:57 PM |
[fitsbits] Comments on proposed FITS draft v3.0 | Peter Weilbacher | FITS | 0 | October 4th 07 03:11 PM |
[fitsbits] FITS MIME Internet Draft | Steve Allen | FITS | 0 | February 15th 05 07:56 PM |
[fitsbits] New draft of WCS Paper IV | Mark Calabretta | FITS | 0 | April 27th 04 05:20 AM |
[fitsbits] New MIME-types-for-FITS RFC draft | Don Wells | FITS | 2 | March 22nd 04 10:31 PM |