Skip to content

Latest commit

 

History

History
79 lines (62 loc) · 4.17 KB

SEP-0008.md

File metadata and controls

79 lines (62 loc) · 4.17 KB
Raw

SEP-0008 - Astropy Time

SEP 8
title Astropy Time
author(s) Stuart Mumford
contact email stuart@cadair.com
date-creation 2018-05-30
type standard
status discussion
discussion sunpy/sunpy#993

Introduction

This SEP proposes that SunPy transitions all internal, and external use of a Python object to represent a date or time from the standard library datetime module to the classes provided in astropy.time. The main classes being replacing datetime.date and datetime.datetime with astropy.Time and replacing datetime.timedelta with astropy.time.TimeDelta.

Detailed Description

Since its inception the SunPy core library has used datetime for handling time. This is a very useful standard library module, however it lacks some key benefits that are provided by Astropy and are useful to the solar community:

  • Support for non-UTC time scales. This is especially useful for JSOC and HMI data which use the TAI time scale rather than UTC.
  • Support for high (double-double) precision time representation and arithmetic.
  • Support for leap seconds.
  • Support for different representations of time, i.e. Julian Day, unix time, GPS.
  • Support for reading and writing the new FITS Time standard.
  • Support for light travel time calculations for different locations on Earth.
  • Support for custom Time scales and formats, i.e. utime.

The astropy.time.Time object can be converted to many different representations of time, i.e. different pre-defined or custom string formats, datetime.datetime objects. This allows users to convert back to datetime objects if needed.

#Accepting Time as Input

All over SunPy when time-like objects are accepted as input, this input must be sanitised with the sunpy.time.parse_time function. This function currently returns a datetime.datetime object. The major API change proposed by the transition to astropy.time is the return value of the parse_time function will become astropy.time.Time. It is also proposed that the function signature of parse_time be standardised with the signature of astropy.time.Time for clarity, the details of this are left to the implementation.

The astropy.time.Time object should be used as an internal representation of time where ever possible, to ensure consistency of things like leap seconds which would not work if datetime were used internally.

Other Changes

Many other parts of SunPy will need to be adapted to work with astropy.time and convert to datetime in as few places as possible to maintain the advantages of the Astropy representation. This will result in the return values of any functions returning time objects also becoming astropy.time.Time objects. It is not expected that there will be any significant changes in functionality.

sunpy.timeseries

It should be noted that because sunpy.timeseries.GenericTimeseries is using Pandas it will not be changed to use astropy.time it would be necessary to migrate from Pandas to astropy.table to gain the advantages of astropy.time. Timeseries data are currently not sufficiently supported by astropy.table. Timeseries support in Astropy table is proposed to be added in APE 9. It is expected that any future implementation of timeseries in Astropy will be evaluated and timeseries potentially adapted to use it. This would be the subject of a separate SEP.

The API of the sunpy.timeseries module will be converted to use astropy.time as appropriate although the actual temporal index of the data (which is the pandas dataframe) will not be changed.

Decision Rationale

Agreed to in Board meeting of 4-Sept-2018. Implemented in SunPy PR#2691.