sunpy/sunpy — pull request #375 by ayshih (2012-12-11 22:03:09+00:00)
Title: Adding functionality to parse_time

I have implemented Jack's feature request (#374) regarding extending parse_time to dive into nested lists and tuples. However, we need to discuss whether it *should* have that functionality. This PR is not to be merged until sufficient discussion has taken place.

>>> import sunpy
>>> sunpy.time.parse_time(['2012-Nov-10',800000000,('2011-10-09',(2010,9,8))])
[datetime.datetime(2012, 11, 10, 0, 0), datetime.datetime(2004, 5, 8, 6, 13, 20), (datetime.datetime(2011, 10, 9, 0, 0), datetime.datetime(2010, 9, 8, 0, 0))]

Note that this implementation requires distinguishing between a tuple of multiple intended times and a tuple of multiple arguments for a single time (fed into the datetime.datetime constructor). As such, there are a few low-impact quirks that actually get introduced:

# These inputs used to produce errors, but no longer do
>>> sunpy.time.parse_time((2012))
datetime.datetime(1979, 1, 1, 0, 33, 32)
>>> sunpy.time.parse_time((2012, 13, 1))
(datetime.datetime(1979, 1, 1, 0, 33, 32), datetime.datetime(1979, 1, 1, 0, 0, 13), datetime.datetime(1979, 1, 1, 0, 0, 1))

Basically, there are some tuples that would have been invalid inputs into the datetime.datetime constructor, but now have valid interpretations (that may not match the user's intent). Conversely, there is the low-impact bug:

# Someone may actually want a tuple of times with exactly these number of seconds since 1979-Jan-01
>>> sunpy.time.parse_time((2012,12,11))
datetime.datetime(2012, 12, 11, 0, 0)

Of course, we can avoid the above issues by having this added functionality only work on nested lists, and have tuples always interpreted as argument-input to datetime.datetime, regardless of whether it is valid or not.

Finally, note that this PR actually contains a bugfix as one of its commits. In principle, I could have included it as two additional PRs, to both the staging and the 0.2 branch, but I thought that'd be excessive. I think it might be "saner" to continue to work on staging, and then cherry-pick together a bugfix PR at a later time.

Discuss!