Not all `astropy.time` formats appear to be supported correctly.' about asdf-astropy

[WilliamJamieson]

Tagging @mhvk and @taldcroft, for their advice on refactoring the time converter:

asdf-astropy/asdf_astropy/converters/time/time.py

Lines 14 to 104 in 816dc57

	class TimeConverter(Converter):
	tags = ["tag:stsci.edu:asdf/time/time-*"]
	types = ["astropy.time.core.Time"]
	def to_yaml_tree(self, obj, tag, ctx):
	from astropy.time import Time
	if obj.format == "byear":
	obj = Time(obj, format="byear_str")
	elif obj.format == "jyear":
	obj = Time(obj, format="jyear_str")
	elif obj.format in ("fits", "datetime", "plot_date"):
	obj = Time(obj, format="isot")
	asdf_format = _ASTROPY_FORMAT_TO_ASDF_FORMAT.get(obj.format, obj.format)
	guessable_format = asdf_format in _GUESSABLE_FORMATS
	if obj.scale == "utc" and guessable_format and obj.isscalar:
	return obj.value
	node = {
	"value": obj.value,
	}
	if not guessable_format:
	node["format"] = asdf_format
	if obj.scale != "utc":
	node["scale"] = obj.scale
	if obj.location is not None:
	# The 1.0.0 and 1.1.0 tags differ in how location is represented.
	# In 1.0.0, there is a single "unit" property that is shared among
	# x, y, and z, and in 1.1.0 each is a quantity with its own unit.
	if tag.endswith("1.0.0"):
	location = {
	"x": obj.location.x.value,
	"y": obj.location.y.value,
	"z": obj.location.z.value,
	"unit": obj.location.unit,
	}
	else:
	location = {
	"x": obj.location.x,
	"y": obj.location.y,
	"z": obj.location.z,
	}
	node["location"] = location
	return node
	def from_yaml_tree(self, node, tag, ctx):
	from astropy import units
	from astropy.coordinates import EarthLocation
	from astropy.time import Time
	if isinstance(node, (str, list, np.ndarray, NDArrayType)):
	time = Time(node)
	asdf_format = _ASTROPY_FORMAT_TO_ASDF_FORMAT.get(time.format, time.format)
	if asdf_format not in _GUESSABLE_FORMATS:
	raise ValueError(f"ASDF time '{node}' is not one of the recognized implicit formats")
	return time
	location = node.get("location")
	if location is not None:
	# The 1.0.0 and 1.1.0 tags differ in how location is represented.
	# In 1.0.0, there is a single "unit" property that is shared among
	# x, y, and z, and in 1.1.0 each is a quantity with its own unit.
	if tag.endswith("1.0.0"):
	unit = location.get("unit", units.m)
	location = EarthLocation.from_geocentric(
	units.Quantity(location["x"], unit=unit),
	units.Quantity(location["y"], unit=unit),
	units.Quantity(location["z"], unit=unit),
	)
	else:
	location = EarthLocation.from_geocentric(
	location["x"],
	location["y"],
	location["z"],
	)
	return Time(
	node["value"],
	format=node.get("format"),
	scale=node.get("scale"),
	location=location,
	)

in general. Any advice on improving/simplifying this object would be great.

[mhvk]

@WilliamJamieson - in newer astropy, the way to ensure precision is not lost when using a string representation is

from astropy.time import Time
t = Time(50000., 1/9, format='mjd')
t.to_value('mjd', 'str')
# '50000.1111111111111111'

Note that this will round-trip for MJD, but not for BYEAR, since the latter involves a calculation that uses a single float. But at least it should be considerably closer.

[WilliamJamieson]

@mhvk, in an offline conversation with @taldcroft, it was suggested that maybe we should use something like Time.info._represent_as_dict(), which should be "stable". This would let us serialize the JD1/JD2 representation that astropy is using to represent the given time, which should round trip?

If this seems like an option, we might require something like a to_dict (or to_yaml) and from_dict method to be added to astropy.time.Time which we could then use a new Converter and schema for.

[mhvk]

@WilliamJamieson - I think explicitly using the methods astropy uses internally to serialize objects makes sense. I'm not quite sure that this would need a method on Time itself, especially since you may well want a similar procedure for SkyCoord. Perhaps instead we should just make our current machinery public? (Could be functions or public methods on .info.)

[WilliamJamieson]

Could be functions or public methods on .info.

This is fine, I just would prefer to use some sort of public interface to both serialize and deserialize (construct) Time objects using the representations astropy works with internally. That way I can rely on the interface being consistent.