[AstroPy] astropy fits time header

[Russell Owen]

To add a bit to what Demitri said: yes DATE (the date at which the HDU was created) is always UTC, but other DATExxxx keywords such as DATE-OBS and DATE-AVG can be in time systems other than UTC. However, you have to specify the time system using the TIMESYS keyword; neither time system nor time zone information can be included in the DATExxxx keyword data.

— Russell

> On Sep 13, 2016, at 8:02 AM, Demitri Muna <demitri.muna at gmail.com> wrote:
> 
> Hi Gijs,
> 
> On Sep 13, 2016, at 10:44 AM, Gijs Molenaar <gijsmolenaar at gmail.com <mailto:gijsmolenaar at gmail.com>> wrote:
> 
>> I noticed that when we use astropy Time fits formatting the time formatting looks like this:
>> 
>> "2016-08-18T14:10:24.695(UTC)"
>> 
>> I think this is actually not according to the fits specification:
>> 
>> https://archive.stsci.edu/fits/fits_standard/node87.html#s:tsys <https://archive.stsci.edu/fits/fits_standard/node87.html#s:tsys>
>> 
>> I noticed this problem when we tried to parse DATE-OBS of such a fits file, we used to be able to parse it with dateutil.parse, but fits files created with this astropy fits format we can't anymore.
>> 
>> Maybe I am wrong?
> 
> That format is (almost) correct. First, the definitive source of the FITS specification is here, not at STScI:
> 
> http://fits.gsfc.nasa.gov/fits_standard.html <http://fits.gsfc.nasa.gov/fits_standard.html>
> 
> The documentation says this:
> 
>> DATE keyword. The value field shall contain a character string giving the date on which the HDU was created, in the form YYYY-MM-DD, or the date and time when the HDU was created, in the form YYYY-MM-DDThh:mm:ss[.sss. . . ], where YYYY shall be the four-digit calendar year number, MM the two-digit month number with January given by 01 and December by 12, and DD the two-digit day of the month. When both date and time are given, the literal T shall separate the date and time, hh shall be the two-digit hour in the day, mm the two-digit number of min- utes after the hour, and ss[.sss. . . ] the number of seconds (two digits followed by an optional fraction) after the minute. Default values must not be given to any portion of the date/time string, and leading zeros must not be omitted. The decimal part of the seconds field is optional and may be arbitrarily long, so long as it is consistent with the rules for value formats of Sect. 4.2.
>> 
>> The value of the DATE keyword shall always be expressed in UTC when in this format, for all data sets created on Earth.
> 
> This matches the ISO 8601 date format (yay standards!):
> 
> https://en.wikipedia.org/wiki/ISO_8601 <https://en.wikipedia.org/wiki/ISO_8601>
> 
> The exception above is that the string "(UTC)" should *not* be part of the date above. Note that this is the definition for the DATE keyword - anyone can define their own keyword and put whatever format they want, but I'd highly recommend sticking with what's prescribed above, i.e. ISO 8601 in UTC. So it depends on what keyword you are using. It's unfortunate that it says that a string like '14/10/96' is acceptable.
> 
> I'm writing a FITS viewer and run fitsverify on every file loaded. Incorrect date formatting is one of the most common reasons I see for a file failing a fitsverify analysis. Please note that files that don't pass fitsverify are technically not valid FITS files.
> 
> https://heasarc.gsfc.nasa.gov/docs/software/ftools/fitsverify/ <https://heasarc.gsfc.nasa.gov/docs/software/ftools/fitsverify/>
> 
> Demitri
> 
> _________________________________________
> Demitri Muna
> http://muna.com <http://muna.com/>
> 
> Department of Astronomy
> Le Ohio State University
> 
> My Projects:
> http://nightlightapp.io <http://nightlightapp.io/>
> http://trillianverse.org
> http://scicoder.org <http://scicoder.org/>
> 
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20160913/ba7dcc5f/attachment.html>