Changed the focus of the PHEP

pheps/phep-9999.md

@@ -1,6 +1,6 @@
 ```
 PHEP: 9999
-Title: PyHC standardization around astropy.time.Time
+Title: PyHC standardization for Python time objects
 Author: Nabil Freij <[email protected]> <https://orcid.org/0000-0002-6253-082X>
 Discussions-To: https://github.com/heliophysicsPy/standards/pull/X
 Revision: 1
@@ -13,30 +13,27 @@ Post-History: 08-July-2024
 
 # Abstract
 
-This PHEP recommends that all projects across the PyHC ecosystem adopt using `astropy.time.Time` as the foundational class for all time objects.
-This process would involve rewriting existing PyHC core packages replace any use of datetime or custom time objects with `astropy.time.Time`.
-Also to prevent the creation of any new custom time objects and use `astropy.time.Time` instead.
+This PHEP recommends that all projects across the PyHC ecosystem use the standard library [datetime](https://docs.python.org/3/library/datetime.html) module or if the project has more complex requirements, they should use `astropy.time.Time` instead of creating their own time objects.
 
-As this is a major change, the transition needs to be carefully managed and will be broken into stages:
+Eventually, we want to encourage that all PyHC libraries allow `astropy.time.Time` as valid time inputs to their libraries.
+This has some roadblocks currently which will not allow this to happen in the near future, but hopefully with the PyHC community behind this PHEP, we can push for better astropy integration with the broader Scientific Python ecosystem.
 
-1. Existing core packages will be reviewed to see how complex their time objects are.
-2. Plans to be drawn up on how to tackle all code changes.
-3. Funding to be found for this work to go ahead.
-
-For any new packages that are being developed or created, they are recommended to use `astropy.time.Time` from the beginning.
+Any existing projects that have their own time object are strongly encouraged to replace their custom time objects with `astropy.time.Time`.
 
 # Motivation
 
 One of the strategic goals of the PyHC Project is to "Coordinate development across projects to minimize duplication of effort".
 
-However, all of the core PyHC packages were created not only before the existence of PyHC,
-but also before many core libraries existed within the wider Scientific Python ecosystem (from `numpy` to `scipy` to `astropy` to `spiceypy` etc). This meant that all PyHC packages had to create their own implementations of time (and other components like coordinates) due to necessity.
+However, all of the core (and non-core) PyHC packages were created not only before the existence of PyHC, but also before many core libraries existed within the wider Scientific Python ecosystem (from `numpy` to `scipy` to `astropy` to `spiceypy` etc).
+This meant that all PyHC packages have had to create their own implementations of time (and other components like coordinates) due to necessity.
 
 Now that the upstream ecosystem has grown at a rapid pace, the need for PyHC package specific implementations has reduced considerably.
 There are at least three areas ("time", "coordinates" and "units") that require standardization, however the focus for this PHEP is to start at "time", as that is considered the *simplest* case for standardization.
 
-The reason that Astropy's time framework was created was to add support for astronomical formats (e.g., Julian Date (JD), Modified JD (MJD) and precise timing (e.g., a nanosecond over a Hubble Time).
-These are not possible when using the Python datetime module.
+To try and address the need to reduce duplication and improve interoperability between PyHC packages, decisions have to be made about reducing the number of ways the community handles the same type of operation but it has to be considered within the wider Scientific Python ecosystem.
+
+For example, the reason that Astropy's time framework was created was to add support for astronomical formats (e.g., Julian Date (JD), Modified JD (MJD) and precise timing (e.g., a nanosecond over a Hubble Time).
+None of which is possible when using the [datetime](https://docs.python.org/3/library/datetime.html) module.
 
 # Rationale
 
@@ -52,8 +49,7 @@ It also adds roadblocks to interoperability if the user needs to change from one
 The focus within PyHC should be to improve the user experience and reduce the walls that block the ever going need to do multi-instrument science.
 
 There is a community worry around funding, however in this authors opinion, the current landscape provides funding opportunity given a targeted proposal.
-For example, "F.7 - Support for Open-Source Tools, Frameworks, and Libraries" or "F.8 - Supplemental Open-
-Source Software Awards" or "B.20 - Heliophysics Tools and Methods" within their stated scope would allow proposals that can fund this refactor work.
+For example, "F.7 - Support for Open-Source Tools, Frameworks, and Libraries" or "F.8 - Supplemental Open-Source Software Awards" or "B.20 - Heliophysics Tools and Methods" within their stated scope would allow proposals that can fund this refactor work.
 
 There has also been worry that reducing the number of implementations would reduce the innovation within the PyHC community.
 The author disagrees as the innovation that is driving the heliophysics field is not in adding more APIs on how to create time objects.
@@ -68,47 +64,30 @@ The adoption of `astropy` is in the authors opinion, the same.
 It provides a new foundation that not only reduces the amount of code within PyHC that handles the same functionality, it allows users to focus on the parts of their work that matter.
 Not only would adding more features to `astropy` benefit the astronomy community, it would in turn benefit the PyHC ecosystem.
 
-# Specification
+The main issue with using `astropy.time` is the lack of support for this index within pandas and xarray.
+The hope is that with this PHEP, we can demonstrate that there is enough desire from this community that we can push for better astropy integration with the broader Scientific Python community.
 
-A dedicated implementation is most likely out of scope for a PHEP, as each package will require bespoke changes after an review.
-
-However, there will be a few common strategies that can be summarized below:
+# Specification
 
-- If a package is using `datetime`, a near one to one drop-in replacement would be quick and is very feasible without dedicated effort.
-- For libraries that provide datetime as inputs, they need to add explicit `astropy.time.Time` support as inputs like for example searching for data.
+- If a package is using `datetime`, nothing changes.
 - For libraries that provide a custom time object, the deprecated of such an object and support for  `astropy.time.Time` would on the surface be simplest.
   Another choice is to rebase the existing time object onto `astropy.time.Time` to avoid breaking existing user code directly.
 
 It is important to note that for new time formats, they do not need to added to `astropy`, they can be in the same PyHC package as they are currently.
 The time framework has been designed to be extendable without adding code changes to `astropy`.
 
-As the merger of this PHEP implies that the PyHC ecosystem are *planning* on standardizing on `astropy.time.Time`, there will be need to be a ecosystem wide plan to enable this transition.
-
-One such transition plan is as follows:
-
-- Review of the existing core PyHC packages to figure out:
-  - What time objects are used?
-  - How would adding `astropy.time.Time` support as function inputs work?
-  - Figure out missing time formats
-  - Figure out missing features from `astropy.time.Time`
-- Figure out how to deal with `astropy.time.Time` lack of support in pandas
-- Creation of a proposal to fund either all or one core PyHC package transitions.
-- **MORE?**
-
 # Backwards Compatibility
 
-This policy introduces backwards incompatibilities by enforcing a new base time object.
+This policy introduces backwards incompatibilities for libraries that have their own custom time object.
 
-To reduce backwards incompatibilities, existing projects will need to add support for `astropy.time` and deprecate old classes or methods.
+To reduce backwards incompatibilities, theses projects might add support for `astropy.time` by making it a valid input for their libraries and emitting a deprecation warning when the old time object is used.
 Within the deprecation message, it would inform users when they would expect their old code to break and provide information on how to transition.
-In other places, it might be possible to take an existing class and underneath make it use `astropy.time` therefore not breaking existing user code for that PyHC core package.
-
-Furthermore, the creation of migration guides so that users can see concrete examples of what changes they will need to make, would ease the burden on users needing to figuring it out alone.
-This can be either hosted on the PyHC website or within the documentation for each package.
+In other places, it might be possible to take an existing class and underneath make it use `astropy.time` therefore not breaking existing user code for that package.
 
 # Security Implications
 
-While we would be requiring `astropy` to be a core dependency of each PyHC project going forward, as  `astropy` already sees widespread use on NASA/NSO and other operational environments.
+For projects using `datetime`, nothing will change.
+For projects that have custom time objects, they would have a `astropy` as a core dependency but as  `astropy` already sees widespread use on NASA/NSO and other operational environments, there should be no new security implications.
 However there might be more of a concern for more tightly controlled operational environments which would need to be investigated.
 
 # How to Teach This
@@ -119,7 +98,7 @@ However there might be more of a concern for more tightly controlled operational
 
 # Reference Implementation
 
-Using `astropy.time` won't involve having one reference implementation.
+Switching to using `astropy.time` instead of custom time objects won't involve having one reference implementation.
 However, both `sunpy` and `plasmapy` use `astropy.time.Time` internally and `sunpy` contains examples of extending `astropy.time.Time` to support extra time formats but also datetime string parsing.
 
 - [New time epoch](https://github.com/sunpy/sunpy/blob/main/sunpy/time/timeformats.py)
@@ -131,10 +110,7 @@ None so far.
 
 # Open Issues
 
-1. What should the time frame be for package transitions?
-2. How do we handle `astropy.time` lack of support in pandas?
-3. Need to figure out what the missing features of `astropy.time` are compared to existing time objects within the PyHC core packages.
-4. How many packages need changing? A ball park evualtion would be useful.
+None so far
 
 # Footnotes