Yes, it parses the input using parse_time.

A bigger problem with this code is the fact that it introduces a different
way of calculating solar ephemerides that are also calculated in other
places, and of course the values are different

The code in util.py is based on sun_pos.pro, which is "based on a truncated
version of Newcomb's Sun and is designed to give apparent angular
coordinates (T.E.D) to a precision of one second of time", according to
sun_pos.pro.

There are several solar ephemeris parameters in sunpy.sun, which is "based
on IDL function get_sun.pro which itself is based on algorithms presented
in the book Astronomical Formulae for Calculators, by Jean Meeus."  This
book was written for people using programmable calculators to calculate
ephemeris information.

We should unify sun_pos.py and sunpy.sun but agree on which calculation to
use.




On Mon, Jun 17, 2013 at 9:49 AM, Steven Christe <notifications@github.com>wrote:

> In sunpy/coords/util.py:
>
> > +    A dictionary with the following keys with the following meanings:
> > +
> > +    longitude  -  Longitude of sun for mean equinox of date (degs)
> > +    ra         -  Apparent RA for true equinox of date (degs)
> > +    dec        -  Apparent declination for true equinox of date (degs)
> > +    app_long   -  Apparent longitude (degs)
> > +    obliq      -  True obliquity (degs)longditude_delta:
> > +
> > +    See Also
> > +    --------
> > +    IDL code equavalent:
> > +        http://hesperia.gsfc.nasa.gov/ssw/gen/idl/solar/sun_pos.pro
> > +
> > +    Examples
> > +    --------
> > +    >>> sp = sun_pos('2013-03-27')
>
> I think we have a coding standard that all times can be passed in a
> strings or datetime objects. The input should always be scrubbed by
> parse_time inside the function.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/sunpy/sunpy/pull/452/files#r4724172>
> .
>