[Python-Dev] iso8601 parsing
wes.turner at gmail.com
Wed Oct 25 22:37:09 EDT 2017
On Wednesday, October 25, 2017, Chris Barker <chris.barker at noaa.gov> wrote:
> On Wed, Oct 25, 2017 at 4:22 PM, Alexander Belopolsky <
> alexander.belopolsky at gmail.com
>> > times. The only difference is that instead of calling the type directly,
>> > you call the appropriate classmethod.
>> > What am I missing?
>> Nothing. The only annoyance is that the data processing code typically
>> needs to know the type anyway, so the classmethod is one more variable
>> to keep track of.
> I don't think anyone is arguing that is is hard to do either way, or that
> hard to use either way.
> I think it comes down to a trade-off between:
> Having an API for datetime that is like the datetime for number types:
> int(str(an_int)) == an_int
> datetime(str(a_datetime)) == a_datetime
> Alexander strongly supports that.
> Or an API that is perhaps more like the rest of the datetime api, which
> has a number of alternate constructors:
> And has:
> So a
> would make a lot of sense.
> I would note that the number types don't have all those alternate
> constructors Also, the number types mostly have a single parameter (except
> int has an optional base parameter). So I'm not sure the parallel is that
> Would it be horrible if we did both?
> After all, right now, datetime has:
> In : dt.isoformat()
> Out: '2017-10-25T16:30:48.744489'
> In : dt.__str__()
> Out: '2017-10-25 16:30:48.744489'
> which do almost the same thing (I understand the "T" is option in iso 8601)
> However, maybe they are different when you add a time zone?
> ISO 8601 support offsets, but not time zones -- presumably the __str__
> supports the full datetime tzinfo somehow. Which may be why .isoformat()
ISO8601 does support timezones.
I might be wrong, but I think many of the third party libraries listed here
default to either UTC or timezone-naieve timezones:
Ctrl-F for 'tzinfo=' in the docs really doesn't explain how to just do it
with my local time.
Here's an example with a *custom* GMT1 tzinfo subclass:
> Though I don't think that means you couldn't have the __init__ parse
> proper ISO strings, in addition to the full datetime __str__ results.
What would you call the str argument? Does it accept strptime args or only
ISO8601? Would all of that string parsing logic be a performance regression
from the current constructor? Does it accept None or empty string?
Deserializing dates from JSON (without #JSONLD and xsd:dateTime (ISO8601))
types is nasty, regardless (try/except, *custom* schema awareness). And
pickle is dangerous.
AFAIU, we should not ever eval(repr(dt: datetime)).
Should the date time constructor support nanos= (just like time_ns())?
ENH: Add nanosecond support to the time and datetime constructors
The astropy Time class supports a string argument as the first parameter
Astropy does support a "year zero".
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev