[fitswcs] Fwd: [fitsbits] Draft WCS Paper V: Time

[Rob Seaman]

Truncated the fitswcs address.

Begin forwarded message:

> From: Rob Seaman <seaman at noao.edu>
> Date: April 6, 2009 4:20:05 PM GMT-07:00
> To: FITSbits <fitsbits at nrao.edu>, fitswcs at nrao.ed
> Subject: Re: [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
>> fitswcs at nrao.edu 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/fitswcs/attachments/20090406/99dcd4ed/attachment.html>