Standardizers extract start and end datetime stamps from headers of uploaded FITS files. The best I can read out from the FITS standard used by Astropy there is no particular set reference time zone in which the dates are expressed in:
As specified by Bunclark & Rots (1997), time zones are explicitly not supported in FITS and, consequently, appending the letter ‘Z’ to a FITS ISO-8601 string is not allowed. The rationale for this rule is that its role in the ISO standard is that of a time zone indicator, not a time scale indicator. As the concept of a time zone is not supported in FITS, the use of time zone indicator is inappropriate
when they are expressed as a datetime stamp for which this information is ambiguous. Really I don't know why we would need to solve this problem instead of just inserting the raw data as-is into our DB but unfortunately, Django ORM datetime stamp is sensitive to differences between naive and non-naive timestamps.
Setting USE_TZ=False in settings.py uses naive timestamps, no timezone information, and vice-versa. FITS files we're testing with come with both naive and non-naive timestamps. It's a matter of choice whether we want to go through the extra effort to ensure all timestamps are timezone aware or not. This change affects Standardizer metadata processing.
Standardizers extract start and end datetime stamps from headers of uploaded FITS files. The best I can read out from the FITS standard used by Astropy there is no particular set reference time zone in which the dates are expressed in:
when they are expressed as a datetime stamp for which this information is ambiguous. Really I don't know why we would need to solve this problem instead of just inserting the raw data as-is into our DB but unfortunately, Django ORM datetime stamp is sensitive to differences between naive and non-naive timestamps.
Setting
USE_TZ=Falseinsettings.pyuses naive timestamps, no timezone information, and vice-versa. FITS files we're testing with come with both naive and non-naive timestamps. It's a matter of choice whether we want to go through the extra effort to ensure all timestamps are timezone aware or not. This change affects Standardizer metadata processing.