The precess package is strange because it uses sexa types in the api. I think there might be another package or two that do this. The motivation is commented in precess but it's outdated, referencing sexagesimal types from base when they have been moved to another package. This is now bad to make people consult another package to understand the api.
A possible solution is to go back to float64s like most other places and just be sure documentation is clear on interpretation of the return values.
Another possible solution is to put types Angle, RA, HourAngle, and Time in base, but without all the sexagesimal support. They would just share the same unit interpretation with the sexagesimal package.
The precess package is strange because it uses sexa types in the api. I think there might be another package or two that do this. The motivation is commented in precess but it's outdated, referencing sexagesimal types from base when they have been moved to another package. This is now bad to make people consult another package to understand the api.
A possible solution is to go back to float64s like most other places and just be sure documentation is clear on interpretation of the return values.
Another possible solution is to put types Angle, RA, HourAngle, and Time in base, but without all the sexagesimal support. They would just share the same unit interpretation with the sexagesimal package.