[Python-Dev] iso8601 parsing
chris.barker at noaa.gov
Wed Oct 25 17:30:00 EDT 2017
+1 on a classmethod constructor
+0 on a based-on-type default constructor
+inf on SOMETHING!
Let's get passed the bike shedding and make this work!
On Wed, Oct 25, 2017 at 2:18 PM, Alex Walters <tritium-list at sdamon.com>
> > -----Original Message-----
> > From: Alexander Belopolsky [mailto:alexander.belopolsky at gmail.com]
> > Sent: Wednesday, October 25, 2017 4:33 PM
> > To: Alex Walters <tritium-list at sdamon.com>
> > Cc: Elvis Pranskevichus <elprans at gmail.com>; Python-Dev <python-
> > dev at python.org>; Chris Barker <chris.barker at noaa.gov>
> > Subject: Re: [Python-Dev] iso8601 parsing
> > On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters <tritium-list at sdamon.com>
> > wrote:
> > > Why make parsing ISO time special?
> > It's not the ISO format per se that is special, but parsing of str(x).
> > For all numeric types, int, float, complex and even
> > fractions.Fraction, we have a roundtrip invariant T(str(x)) == x.
> > Datetime types are a special kind of numbers, but they don't follow
> > this established pattern. This is annoying when you deal with time
> > series where it is common to have text files with a mix of dates,
> > timestamps and numbers. You can write generic code to deal with ints
> > and floats, but have to special-case anything time related.
> >>> repr(datetime.datetime.now())
> 'datetime.datetime(2017, 10, 25, 17, 16, 20, 973107)'
> You can already roundtrip the repr of datetime objects with eval (if you
> care to do so). You get iso formatting from a method on dt objects, I
> don’t see why it should be parsed by anything but a classmethod.
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev