Cleanup and improve PHOTOMETRY.TIME parameter

[lzkelley]

• ~~The time restrictions should likely be less stringent (i.e. not require that the time is a number, or contains '-' or '/'; see: https://github.com/astrocatalogs/astrocats/blob/4463d65fe9f10fcd84f2c37f3fa8b6f147ed5668/astrocats/catalog/key.py#L248).~~

• It doesn't make sense to allow for a(n arbitrary) U_TIME parameter if the TIME ends up being converted to MJD anyway.

[guillochon]

The idea here was we have a "favored" unit for time, MJD, but if a user hand-writes a JSON file with a different unit, they should be able to specify it and have astrocats understand it. Upon being imported into astrocats and the final JSON written to disk, times would be converted to the "favored" unit.

[guillochon]

And on the first bullet: Are you thinking dates in the form of English words, like "November 12, 1984"? Ideally the check would be to see if it parses in a date parser, but unfortunately the date parsers in Python are very inflexible (and unintelligent). I think astropy's time module is a bit better, but still rather inflexible.

[lzkelley]

Yeah, I think the favored time unit is good. It looks like I was having problems because of me, not it (it seemed that passing in a string version of the time was failing --- not true; and issue updated). So the only thing is that it seems a little strange how the conversion is done: maybe just delete the U_TIME parameter if its converted... Also, I found this package a while ago that does some pretty impressive matching for datetime specifications:

https://dateutil.readthedocs.io/en/stable/