Blog - Posts tagged sunpy

SunPy Awarded NASA Grant

2021-11-03T00:00:00+00:00

As part of the NASA “Open Source Tools, Frameworks, and Libraries” program, the SunPy proposal “Strengthening the Foundations of the SunPy Ecosystem” has been funded for the next three years.

This proposal was submitted in January 2021, and sought funding for both the core sunpy package and wider goals of the project. After early community input was collected, Albert Shih led the proposal itself, with NASA GSFC as the primary institution. The proposed effort focuses on three main areas:

Improving the technical infrastructure.

This focuses on the tools that the wider project needs to scale up as we adopt more coordinated and affiliated packages. To support multiple active projects with a common development workflow, more tooling and infrastructure is needed, both for maintainers of existing packages and developers new to writing affiliated packages. As part of this work templates for setting up new packages will be improved, documentation will be written, and new automation and monitoring bots will be developed to ease the burden on the SunPy maintainers.
Augmenting science-enabling functionality.

This section aims to improve the tools provided by the core package to better support future challenges in solar physics data. The two main components of this are supporting multi-point observations with improvements to the sunpy.coordinates package, and improving the support for very large datasets in sunpy and sponsored packages by leveraging the scaling and parallelism tools available from Dask.
Providing training and outreach

This section will improve example galleries across both sunpy core and affiliated packages, develop training materials for solar physics graduate students, and perform outreach activities with instrument teams and package developers.

What will the money pay for?

The money awarded to this proposal will pay for:

Albert Shih will manage the project and augment parts of sunpy.coordinates.
Stuart Mumford will work on infrastructure for all sponsored and affiliated packages as discussed in sunpy/sunpy-project#2.
Will Barnes will work on the training/outreach and large-dataset-support components of the project.

Finally

This is a major milestone for SunPy - it is the first significant amount of funding dedicated to directly working on the long term sustainability of the project. This funding will help to significantly grow SunPy, both the core package and the ecosystem of associated packages.

October Release Announcements

2021-10-29T00:00:00+00:00

Today we have a quadruple release announcement for you! It’s been a very busy week in SunPy land getting both the core and ndcube releases over the line; I hope you enjoy them!

sunpy 3.1

The next scheduled release of the sunpy core package actually comes a week early according to our release calendar, but we couldn’t resist bringing you this end of month release party.

The 3.1 release contains many new features and improvements, having merged 145 pull requests from 16 people including 8 new contributors.

Some of the highlights from the What’s New in SunPy 3.1? page are:

Increased in-situ data support
A new limb drawing function
A new WISPR map source
Propagating solar-surface coordinates in time
Convenient reprojection of maps
JSOC keyword filtering with Fido
Arithmetic operations with maps

My personal favourites being the new limb drawing function and the reproject_to method on all maps.

ndcube 2.0

Even more excitingly, for me personally, is the long awaited 2.0 release of ndcube.

ndcube is the sunpy sponsored package for working with multi-dimensional data with an associated WCS object. For an introduction to ndcube and motivation for the 2.0 rework see An introduction to ndcube.

We started working on ndcube 2.0 back in 2019 when we had Yash Sharma do the initial work of porting the code base to use the APE 14 APIs as his Google Summer of Code project. Little did any of us think that it would take over two years from that point to hit the final release.

The road to ndcube 2.0 has been long and arduous; all involved have put in a lot of work and what we have made is something that I am personally very proud of. ndcube 2.0 would not have happened without Dan Ryan, who as the co-maintainer for ndcube has spent many hours on video calls with me designing APIs, and many more hours besides working out problems you would only encounter in one in a million WCS objects! I would also be remiss if I didn’t specifically thank the DKIST data center who have, by paying for my time, funded a lot of the development work on ndcube 2.0, even when the scope increased beyond their direct requirements.

I hope that many packages will start using ndcube 2.0 as the base for their code. There are already many who have helped to shape the release such as the DKIST User Tools, specutils and sunraster as well as others I know are in the works.

For all the gory details of the changes in ndcube 2.0 see the changelog.

pfsspy 1.0

The SunPy-affiliated potential field source surface extrapolation package pfsspy maintained by David Stansby has had a 1.0 release, which includes promises of API stability. You can read about all the changes in the changelog.

aiapy 0.6

The SunPy-affiliated aiapy package, which provides tools for working with SDO/AIA data and is maintained by the AIA instrument team, has a new 0.6 release which includes support for sunpy core 3.1. In addition to a number of bug fixes, v0.6 also includes the ability to calculate uncertainties on AIA images via the estimate_error function. A complete list of changes is available in the changelog.

The What, Why, and How of SunPy Affiliated Packages

2020-08-18T00:00:00+00:00

What are SunPy affiliated packages?

SunPy affiliated packages are well-maintained, open-source software packages that build upon or extend the functionality of the SunPy core library. The main idea behind affiliated packages is to provide additional tools and functionality to the solar physics community that is considered outside the scope of the SunPy core library, but builds upon it. Affiliated packages are aimed to integrate well with the SunPy ecosystem and together with the core library offer a diverse software ecosystem for which to perform solar data analysis. Affiliated packages are reviewed and registered with the SunPy project.

There are two types of affiliated packages - sponsored and non-sponsored. A sponsored affiliated package is an affiliated package that is maintained and overseen by the SunPy project, examples of these include sunpy core and ndcube. Non-sponsored affiliated packages on the other hand remain under the control and maintenance of the original developers, but must meet a set of standards. Examples of non-sponsored affiliated packages would be instrument-specific affiliated packages such as AIApy.

In this blog post we want to outline our new streamline process for becoming an affiliated package and we want to encourage package developers, particularly instrument teams interested in developing a Python package, to submit their package for review for SunPy affiliate status!

Why would a package want to become an affiliated package?

SunPy supports the development of affiliated packages through our community development efforts and by providing our package template. The SunPy project will also ensure that affiliated packages are publicized to encourage community development. For example, affiliated packages are listed on the SunPy website, and SunPy adverstises them at conferences and workshops.

Call to instrument/mission teams!

We invite instrument and mission teams that are interested in developing a Python package to become a SunPy affiliated package. Integrating mission/instrument-specific software within the SunPy ecosystem will be of great benefit to the solar community and will allow for a simplified and unified process for users to perform solar data analysis. For example, a package may consist of instrument-specific calibration routines which would be outside the scope of SunPy core package, but could build upon the functionality provided by core such as the data containers and file readers. Developing a mission/instrument specific package as a SunPy affiliated package will allow the code to live and integrate within the SunPy ecosystem.

Furthermore, for mission/instrument teams that would like to begin developing specific Python software, the SunPy project offers support through our package template and community resources for the package to be ‘incubated’ until it is at the level of affiliate status. We would really like to encourage instrument/mission teams to reach out!

Package template

The SunPy project is currently developing a package template that is designed to help developers create new Python packages within the SunPy ecosystem. The template is still in development, and we are working towards creating more documentation to make it accessible for developers to use. The idea is that this template will provide a simplified way to standardized packaging, testing, and documentation using the same framework as the SunPy core package. The SunPy package template will make it easier for package developers to meet the standards required by SunPy to become an affiliated package!

How does a package become an affiliated package?

To become a SunPy affiliated package, a set of criteria need to be met to ensure that affiliated packages provide useful functionality to the community at a standard of quality similar to the core SunPy package. We now have a new review process for becoming an affiliated package, aimed at being open, approachable and streamlined!

The reviews are performed as an open process through GitHub issues on the https://github.com/sunpy/sunpy.org repository. To submit a package for review to become an affiliated package, an issue should be opened on this repository. We now have an issue template for submitting a package for review to make it easier to provide all the required information and to start a dialogue about the process.

Once an issue is open, the Affiliate Package Liaison will check that the package meets the baseline requirements of an affiliated package. These include checking to see that it is compatible with the SunPy Code of Conduct, has an appropriate licence, provides a Python interface, is on PyPI, and is useful to the solar physics community. Following this, a reviewer independent to the package is assigned and a review is undertaken based on the criteria listed below.

The review criteria that are assessed are listed as follows with the associated gradings:

Functionality Does the package provide functionality that is useful and relevant to the solar physics community?
Integration - Does that package integrate well within the SunPy ecosystem? for example does it make use of all appropriate features in the core library, including the applicable data structures and dependencies?
Documentation - Does the package have satisfactory documentation that is up to the standard of the core sunpy library including a user guide and examples?
Testing - Does the package use a testing suite to verify the code functionality within its codebase? Does it provide integration tests?
Duplication - Does the package duplicate functionality within sunpy core or any of the other affiliated packages or other relevant packages?
Community - Is the package openly developed with active input and engagement from users within the community? Does the package have a code of conduct and does this reflect the same values as the SunPy project?
Development Status - Is the package well maintained? Are contribution responded to by developers? Is the package still under development with large API changes?

These criteria are reviewed on a ‘traffic light’ system and ranked ‘green’, ‘orange’, or ‘red’ based on the submitted package. For full details of how each of criteria are ranked please check out the Review Criteria.

For a submitted package to be accepted to affiliate package status, the package must be ‘green’ in Functionality, and one other category. It must also not list any ‘red’ scores.

If the package in its current state does not pass the criteria, it can be listed as Provisional once it does not list ‘red’ in the Functionality, Duplication or Community criteria. The idea is that the package can be listed as Provisional as it is working towards addressing the criteria for which it did not pass the review in.

We would really like to encourage packages interested in becoming an affiliated SunPy package to please submit an issue and open up a review dialogue. We will have an Affiliated Package Liaison that will help you through each step of this process :). Even if you are unsure about whether you want to submit a package, please feel free to open an issue and informally discuss your package.

Reach out!

If you are a developer of a package that you think fits nicely into the SunPy ecosystem and will of benefit to the solar physics community and want to chat to us about it please reach out! This can be of course regardless of how far along the package is - from concept to maturity! Join us our live chat Matrix room or join in on the SunPy weekly community meetings which occur each Wednesday (see our calendar for the time in your timezone) and are hosted on jitsi.

SunPy 2.0 Released

2020-06-12T00:00:00+00:00

The SunPy project is happy to announce the release of SunPy 2.0! SunPy is an open-source Python library for Solar Physics data analysis and visualization.

This release is our second long(er) term support release, that we will be supporting with bug fixes until 3.0 in roughly a year’s time. With this release, the 1.0 and 1.1 releases will no longer receive bug fixes and we encourage everyone to upgrade to 2.0.

The major highlights of this release are:

Fido now supports tab completion of search attributes. This allows you to do a.Instrument.AIA, and print a.Instrument to see the list of known supported instruments.
aiaprep has been deprecated in favor of the functionality in the aiapy package.
Various fixes and clarifications to pixel indexing in the sunpy.map subpackage.
Standardization of specifying rectangles in coordinate space in the submap() and draw_rectangle() methods of GenericMap.
HTML quicklook previews of GenericMap and MapSequence instances are available with the new quicklook() and quicklook() methods, respectively. This is also the default display in Jupyter notebooks.
Integration of differential rotation into the sunpy.coordinates framework. This enables, amongst other things, the warping of images with the reproject package and the plotting of rotated grid lines with WCSAxes.

See What’s New in SunPy 2.0 for more details and the Full Changelog for the full list of over 100 changes in 2.0.

This release of SunPy contains 1044 commits in 290 merged pull requests closing 144 issues from 33 people, 16 of which are first-time contributors to SunPy.

The people who have contributed to the code for this release are:

Abhijeet Manhas * Abijith B * Albert Y. Shih Amogh J * Arfon Smith * Arib Alam * David Pérez-Suárez David Stansby Deepankar Sharma Jack Ireland Jai Ram Rideout James Paul Mason Kris Akira Stern * Laura Hayes Lazar Zivadinovic * Mark Cheung * Monica Bobra Nabil Freij Ole Streicher Pankaj Mishra * Raahul Singh Rajiv Ranjan Singh Rutuja Surve * Sarthak Jain Sashank Mishra * Steven Christe Stuart Mumford Swapnil Kannojia * Utkarsh Parkhi * Will Barnes abijith-bahuleyan * honey * mridulpandey *

Where a * indicates their first contribution to SunPy.

SunPy awarded a NASA HDEE Grant

2020-06-05T00:00:00+00:00

A NASA Heliophysics Data Environment Enhancement (HDEE) grant has been awarded to a proposal submitted to support SunPy development. The grant was awarded through NASA’s 2019 ROSES grant solicitation.

The grant supports the following development goals:

Creation of a report on the state of the SunPy codebase by analyzing output from code coverage and API inspection tools, etc, identifying areas in the existing codebase that need more coverage, can be consolidated or removed.
Provide the ability to read spectroscopic data into a spectral data object, thereby enabling its later scientific analysis.
Implement a number of heliophysical coordinate systems using the existing SunPy and Astropy-based coordinate system framework.
Create example code snippets that use SunPy and packages from the Python in Heliophysics Community; these examples will be shared via the Python in Heliophysics Community.

The PI of the grant is Jack Ireland, and the co-I of the grant is Andy Terrel (NumFOCUS). The grant has a one year duration. The bulk of the code development will be undertaken by a developer hired through NuMFOCUS. We look forward to supporting the development of SunPy through this grant.

Jack

SunPy Survey

2020-04-27T00:00:00+00:00

The SunPy project is happy to announce the results of the solar physics community survey!

For six months last year, between February and July 2019, the SunPy Project asked the solar physics community to fill out a 13-question survey about software and hardware. Some of the questions were: Do you use software in your research? Have you had formal training in programming? Have you cited software papers in your published research?

We deliberately asked some of the same questions as Momcheva and Tollerud (2015), who informally surveyed 1142 members of the astrophysics community, to compare software preferences between the two communities. A total of 364 community members, across 35 countries, took our survey.

What we found

We found that 99±0.5% of people who responded to our survey use software in their research. Nearly everyone in the solar physics community relies on scientific software. A large fraction (66%) of respondents use Python. Most respondents use both Interactive Data Language (IDL) and Python.

However, students are twice as likely as faculty, staff scientists, and researchers to use Python. This breakdown is pretty different from the astrophysics community, where Momcheva and Tollerud (2015) found that Python is the most popular programming language within every individual career category.

We also found that most respondents (63±4%) haven’t taken any computer science courses at an undergraduate or graduate level. Momcheva and Tollerud (2015) also found that most astrophysicists also lack formal training in software development.

Most of the people who responded to our survey work with observational data taken by ground-based or space-based instruments (82%). And about half (47%) work with numerical simulations. Some work in both sub-disciplines. Although some instruments and numerical models in solar physics generate sizeable data volumes, only a small fraction of respondents use a regional cluster, national cluster, or the commercial cloud for their research.

Finally, we found that 42±3% of respondents regularly cite scientific software. Half the respondents who don’t cite software said they didn’t know how.

Our paper

Please check out our paper! We detailed all of these results, and more, in a paper published on April 20, 2020 (DOI: 10.1007/s11207-020-01622-2). We also included an appendix on how to cite scientific software. You can also take a look at all the raw survey responses (anonymized and randomized), along with the code to analyze these data, at github.com/sunpy/survey.

SunPy 1.1 Released

2020-01-10T00:00:00+00:00

The SunPy project is happy to announce the release of SunPy 1.1! SunPy is an open-source Python library for Solar Physics data analysis and visualization.

This release is our first major release post-1.0 and part of our new release pattern.

The major highlights of this release are:

The coordinates subpackage now supports four additional coordinate frames (HCI, HEE, GSE, and GEI).
A new subpackage sunpy.data.data_manager has been added to support versioned data for functions and methods.
Support in sunpy.map and sunpy.net for the SUVI instrument on GOES satellites.
Initial support for WISPR data from Parker Solar Probe in sunpy.map.
The import times for sunpy and some subpackages are significantly shorter, with no loss of functionality.

See What’s New in SunPy 1.1 for more details and the Full Changelog for the full list of over 100 changes in 1.1.

If you use conda, you can update to this release by running:

$ conda install -c conda-forge sunpy

or, if you use pip, by running:

$ pip install -U sunpy

If you haven’t already installed SunPy we recommend you follow our Installation Guide.

By the numbers

This release of SunPy contains 1137 commits in 242 merged pull requests closing 106 issues from 24 people, 10 of which are first time contributors to SunPy.

The people who have contributed to the code for this release are:

Albert Y. Shih
Arthur Eigenbrot
Brigitta Sipocz
David Pérez-Suárez
David Stansby
Dominik Stańczak *
Guntbert Reiter *
Himanshu Pathak *
Jack Ireland
Juanjo Bazán *
Laura Hayes
Michael S Kirk
Nabil Freij
Quinn Arbolante *
Raahul Singh *
Rajiv Ranjan Singh *
Steven Christe
Stuart Mumford
Tom Augspurger *
Vishnunarayan K I.
Will Barnes
Yash Sharma
neerajkulk *

Where a * indicates their first contribution to SunPy.

Happy Pythoning,

Stuart

SunPy Release Schedule and Version Numbering

2019-06-27T00:00:00+00:00

In this blog post I want to outline how, and more over why, we are going to number the SunPy releases and when we are going to release them.

TLDR; we are going to move to a 6 month release cadence, with a Long Term Support (one year of support) release in May and a Short Term Support (6 months of support) in November. We will increment the major version number for each LTS release.

Background

As part of the 1.0 release planning the SunPy developers and the board spent a long time discussing how we want to version SunPy and what we want to use our versioning a release schedule to achieve. We went through two major iterations of this plan, the first can be found in the abandoned PR to the SunPy Enhancement Proposal repository #30, and the second one which was accepted in #40.

Objectives

In moving SunPy out of the 0.y series of releases we knew that our users would be expecting us to make breaking changes less, and for them to be able to rely on SunPy for longer.

We wanted to balance the desire for people to be able to start using SunPy for a project and be able to see that project through without having to constantly adjust to many changes in new releases. On the other hand, we wanted to also allow the development of SunPy to continue without having to delay people contributing improvements to SunPy because of a strict versioning scheme.

We also have to consider that, currently, SunPy core is developed entirely by volunteers, and supporting old versions of the library is a time consuming and sometimes thankless job.

Releases

The solution we landed on is to provide a Long Term Support release that we will support for one year (i.e. until the following LTS release). This gives people who want stability a release schedule where they get bug fixes for a year. While also allowing SunPy to do releases on a six month cycle to get new features out for people to use.

To make it clear which releases are Long Term Support releases, we will increment the major version (the first number) for each LTS release. This means SunPy 1.0 is a LTS release which we will be supporting until the release of 2.0 in May 2020.

The all the non-LTS releases between the LTS releases will increment the minor version number, as there is only one release planned between LTS releases the normal release number will be 1.0, 1.1, 2.0, 2.1 etc.

Deprecations

We still expect, and have plans for, changes to many parts of SunPy. We believe these changes will enable even more people to find SunPy useful in their work.

To enable people to prepare for changes and to not be in for big surprises when updating SunPy we will endeavour to emit a deprecation warning for any breaking changes for one LTS release.

The upshot of this is that, if now after 1.0, we want to change something in a backwards incompatible way we would continue to provide both the old and new ways until after the 2.0 release. The 2.0 release would emit a deprecation warning, to give people who go from LTS to LTS a year to update their code before the next LTS.

Conclusion

I hope this blog post gives you some insight into how we made this decision and why, if you have any comments please don’t hesitate to get in touch using any of the usual ways.

SunPy 1.0 Released

2019-06-01T00:00:00+00:00

The SunPy project is happy to announce the release of SunPy 1.0.0!

This release has been in development for 14 months, and is a large change from the 0.x series of SunPy releases with a lot of old functionality removed and some exciting new features.

The major highlights of this release are:

A complete transition of the whole code base to use astropy.time.Time, which was implemented by Vishnunarayan K I as part of Google Summer of Code 2018.
A rewrite of how all the clients in sunpy.net download files from the internet. This means vastly improved progress bars, skipping downloads if files are present, and better visibility and retrying of download errors.
A rewrite of the differential rotation and image warping code to correctly account for observer location using the Astropy coordinate functionality.
Removal of many deprecated functions and submodules; we have used the 1.0 release as a chance to clean out SunPy reducing the number of lines of Python code in the project by almost 3,000!
The first release of SunPy to be Python 3 only, requiring Python 3.6+.

See What’s New in SunPy 1.0 for more details and the Full Changelog for the full list of over 150 changes in SunPy 1.0.

This release includes many breaking changes and may require your code to be updated to support it. We hope you see the value in having the extra features these changes have enabled and a code base that is easier to maintain. We will be continuing to release bug fixes to the 0.9.z series until the end of 2019. We hope this gives you enough time to update your code and start enjoying all the improvements in SunPy 1.0.

If you use conda, you can update to this release by running:

$ conda install -c conda-forge sunpy

or, if you use pip, by running:

$ pip install -U sunpy

If you haven’t already installed SunPy we recommend you follow our Installation Guide.

By the numbers

This release of SunPy contains 1913 commits in 332 merged pull requests closing 582 issues from 46 people, 25 of which are first time contributors to SunPy.

The people who have contributed to the code for this release are:

Abhigyan Bose *
Airmansmith97 *
Albert Y. Shih
Andre Chicrala *
Andrew Hill *
Andrew Inglis
Andrew Leonard
Arthur Eigenbrot *
Bernhard M. Wiedemann *
Brandon Stone *
Brigitta Sipocz
Daniel D’Avella
Daniel Ryan
David Pérez-Suárez
David Stansby
Deepankar Sharma *
Emmanuel Arias *
Harsh Mathur *
Jack Ireland
Jacob *
Jai Ram Rideout *
Larry Manley
Laura Hayes *
Manas Mangaonkar *
Matthew Mendero *
Md Akramul Haque *
Michael S Kirk
Mickaël Schoentgen *
Monica Bobra *
Nabil Freij
Naman9639 *
Prateek Chanda
Punyaslok Pattnaik
Reid Gomillion *
Sarthak Jain *
Shane Maloney
Shresth Verma
Sourav Ghosh *
Steven Christe
Stuart Mumford
Vishnunarayan K I.
Will Barnes
Yash Jain
Yash Krishan *
Yash Sharma *
jamescalixto *

Where a * indicates their first contribution to SunPy.

On a personal note, I am very excited to see SunPy reach this milestone; watching the community around this project grow since I got involved has been incredible. The sunpy library is almost unrecognisable from where it was when I got involved shortly after the 0.2 release, which is the result of countless hours of work by over 100 people. I want to thank everyone who has contributed to SunPy in any way that helped us get to the point where we felt the library deserved the 1.0 label. I especially want to thank Nabil Freij who has done so much behind the scenes work to keep things moving forward, and done such a good job helping new contributors get pull requests into SunPy.

I am very excited to see where SunPy goes next.

Happy Pythoning,

Stuart

Transition from datetime to astropy.time

2018-10-20T00:00:00+00:00

This blog post was written in a Jupyter notebook. Click here for an interactive version:

The SunPy project is very happy to announce that the time handling in SunPy will be transitioned from python datetime module to astropy.time module. The changes for this transition are under review in the pull request #2691. These changes are scheduled for SunPy 1.0.

This comes with numerous benefits:

Support for non-UTC time scales

UTC as well as non-UTC time scales like TAI, TT, UT1 etc. can be used with astropy.time.Time.

[1]:

from astropy.time import Time

t = Time("2012-06-18T02:00:05.453", scale="tai")
t

[1]:

<Time object: scale='tai' format='isot' value=2012-06-18T02:00:05.453>

~astropy.time.Time also provides easy conversion between different scales.

[2]:

t.utc

[2]:

<Time object: scale='utc' format='isot' value=2012-06-18T01:59:31.453>

Support for high precision times.

~astropy.time.Time can provide sub-nanosecond precision for time objects while python datetime was restricted to microseconds.

[3]:

t.precision = 9
t

[3]:

<Time object: scale='tai' format='isot' value=2012-06-18T02:00:05.453000000>

Support for leap seconds

This was one of the bigger motivation for the transition to astropy.time.Time. datetime has no support for leap second while ~astropy.time.Time supports leap seconds. A leap second is a one-second adjustment applied to UTC to keep it close to the mean solar time.

[4]:

import astropy.units as u

Time("2016-12-31T23:59:60"), Time("2016-12-31T23:59:59") + 1 * u.s

[4]:

(<Time object: scale='utc' format='isot' value=2016-12-31T23:59:60.000>,
 <Time object: scale='utc' format='isot' value=2016-12-31T23:59:60.000>)

Support for numerous formats

~astropy.time.Time can parse numerous formats including python datetime.

[5]:

Time.FORMATS

[5]:

OrderedDict([('jd', astropy.time.formats.TimeJD),
             ('mjd', astropy.time.formats.TimeMJD),
             ('decimalyear', astropy.time.formats.TimeDecimalYear),
             ('unix', astropy.time.formats.TimeUnix),
             ('cxcsec', astropy.time.formats.TimeCxcSec),
             ('gps', astropy.time.formats.TimeGPS),
             ('plot_date', astropy.time.formats.TimePlotDate),
             ('datetime', astropy.time.formats.TimeDatetime),
             ('iso', astropy.time.formats.TimeISO),
             ('isot', astropy.time.formats.TimeISOT),
             ('yday', astropy.time.formats.TimeYearDayTime),
             ('datetime64', astropy.time.formats.TimeDatetime64),
             ('fits', astropy.time.formats.TimeFITS),
             ('byear', astropy.time.formats.TimeBesselianEpoch),
             ('jyear', astropy.time.formats.TimeJulianEpoch),
             ('byear_str', astropy.time.formats.TimeBesselianEpochString),
             ('jyear_str', astropy.time.formats.TimeJulianEpochString)])

[6]:

import datetime

Time(datetime.datetime.now(tz=datetime.timezone.utc))

[6]:

<Time object: scale='utc' format='datetime' value=2019-03-20 19:19:05.112429>

Changes to SunPy

All functions which used to return datetime now return ~astropy.time.Time
- All functions which return datetime.timedelta now return astropy.time.TimeDelta. For example, the properties of sunpy.time.TimeRange which used to return datetime.datetime and datetime.timedelta now return astropy.time.Time and astropy.time.TimeDelta.
Changes to sunpy.time.parse_time
- ~sunpy.time.parse_time has been reduced to a tiny wrapper over~astropy.time.Time. The API of ~sunpy.time.parse_time is mostly similar to that of ~astropy.time.Time. ~sunpy.time.parse_time supports parsing a few more formats than ~astropy.time.Time, which are numpy.datetime64, pandas.Series, pandas.DatetimeIndex, “UTime” and a few other time formats.

The work on the transition from datetime to astropy.time.Time was done as a part of Vishnunarayan’s Google Summer of Code 2018 project. To see more about the project:

Vishnunarayan’s Medium Blog Posts