datetime iso8601 string input

[Rubic]

I was a little surprised to recently discover
that datetime has no method to input a string
value. PEP 321 appears does not convey much
information, but a timbot post from a couple
years ago clarifies things:

http://tinyurl.com/epjqc
[color=blue]
> You can stop looking: datetime doesn't
> support any kind of conversion from string.
> The number of bottomless pits in any datetime
> module is unbounded, and Guido declared this
> particular pit out-of-bounds at the start so
> that there was a fighting chance to get
> *anything* done for 2.3.[/color]

I can understand why datetime can't handle
arbitrary string inputs, but why not just
simple iso8601 format -- i.e. the default
output format for datetime?

Given a datetime-generated string:
[color=blue][color=green][color=darkred]
>>> now = str(datetime.da tetime.now())
>>> print now[/color][/color][/color]
'2006-02-23 11:03:36.762172 '

Why can't we have a function to accept it
as string input and return a datetime object?

datetime.parse_ iso8601(now)

Jeff Bauer
Rubicon, Inc.

[Magnus Lycka]

Re: datetime iso8601 string input

Rubic wrote:[color=blue]
> I can understand why datetime can't handle
> arbitrary string inputs, but why not just
> simple iso8601 format -- i.e. the default
> output format for datetime?[/color]

Have you actually read the ISO 8601 standard?
If you have, you would know that parsing valid
ISO 8601 is fairly close to handling arbitrary
strings...

I suspect this absence is quite deliberate.

There are so many possible string formats that
are used and prefered in different situations,
and various loop holes with time zones and DST
etc, that it's probably better to let the
programmer take full responsibility over this
instead of providing a 10% solution.

ater all, it isn't very hard to use for instance
time.strptime() with some appropriate format,
and build datetime objects from that. Then
the programmer is in control.

[Rubic]

Re: datetime iso8601 string input

Magnus,

Thanks for your reply. I wasn't clear in my
prior post. Rather than support the entire
range of iso8601 formats, how about *just* the
format that datetime emits? Call it the
parse_datetime( ) function. Then it would be
possible to take the output string of a datetime
object and read it back in to round-trip the
data.
[color=blue][color=green][color=darkred]
>>> now = str(datetime.da tetime.now())
>>> now[/color][/color][/color]
'2006-02-24 06:58:23.737586 '[color=blue][color=green][color=darkred]
>>> datetime.parse_ datetime(now)[/color][/color][/color]
datetime.dateti me(2006, 2, 24, 6, 58, 23, 737586)

Jeff Bauer
Rubicon, Inc.

[Peter Hansen]

Re: datetime iso8601 string input

Rubic wrote:[color=blue]
> Thanks for your reply. I wasn't clear in my
> prior post. Rather than support the entire
> range of iso8601 formats, how about *just* the
> format that datetime emits? Call it the
> parse_datetime( ) function. Then it would be
> possible to take the output string of a datetime
> object and read it back in to round-trip the
> data.
>[color=green][color=darkred]
> >>> now = str(datetime.da tetime.now())
> >>> now[/color][/color]
> '2006-02-24 06:58:23.737586 '[color=green][color=darkred]
> >>> datetime.parse_ datetime(now)[/color][/color]
> datetime.dateti me(2006, 2, 24, 6, 58, 23, 737586)
>
> Jeff Bauer
> Rubicon, Inc.[/color]

If that's truly all you want, then it's a near trivial function to
write. One of those "throw-away" functions you tend to whip up a few
dozen times on every project, hardly noticing because you're using
Python and it's so easy to do.

-Peter

[Rubic]

Re: datetime iso8601 string input

Yeah, it's a trivial function that's rewritten for each new project
that passes datetime objects as strings <0.2 wink>. On the basis of it
being a trivial convenience, I could propose removing hundreds of
"redundant" functions from the library. ;-)

Never mind. I'll drop it.

Jeff Bauer
Rubicon, Inc.

[Magnus Lycka]

Re: datetime iso8601 string input

Rubic wrote:[color=blue]
> Yeah, it's a trivial function that's rewritten for each new project
> that passes datetime objects as strings <0.2 wink>. On the basis of it
> being a trivial convenience, I could propose removing hundreds of
> "redundant" functions from the library. ;-)[/color]

I think the big issue is that it solves such a microscopic part
of the convert-strings-to-datetimes problem. Believe me, I know,
I'm writing parsers for IATA timetable data now. There is a
distinct smell of punch cards, telex machines and handwritten
forms in this standard... Like writing 112233 instead of 2006-
02-11 22:33, and let the parser guess month and year from context.

If I have gotten a time into a datetime object I'll keep it there
if I'm in control. If I'm not in control, I'd be very lucky if
the string replresentation was in the One True Format.

Since I feel that the datetime module largely replaces the
older time module, I'd really like to see a strptime in the
datetime module though. Then I guess I could often drop use of
the old time module. (If it wasn't for the sad fact that we need
to support Python 2.2 a little longer...)

[aurora]

Re: datetime iso8601 string input

I agree. I just keep rewriting the parse method again and again.

wy

def parse_iso8601_d ate(s):
""" Parse date in iso8601 format e.g. 2003-09-15T10:34:54 and
returns a datetime object.
"""
y=m=d=hh=mm=ss= 0
if len(s) not in [10,19,20]:
raise ValueError('Inv alid timestamp length - "%s"' % s)
if s[4] != '-' or s[7] != '-':
raise ValueError('Inv alid separators - "%s"' % s)
if len(s) > 10 and (s[13] != ':' or s[16] != ':'):
raise ValueError('Inv alid separators - "%s"' % s)
try:
y = int(s[0:4])
m = int(s[5:7])
d = int(s[8:10])
if len(s) >= 19:
hh = int(s[11:13])
mm = int(s[14:16])
ss = int(s[17:19])
except Exception, e:
raise ValueError('Inv alid timestamp - "%s": %s' % (s, str(e)))
return datetime(y,m,d, hh,mm,ss)

[color=blue]
> I was a little surprised to recently discover
> that datetime has no method to input a string
> value. PEP 321 appears does not convey much
> information, but a timbot post from a couple
> years ago clarifies things:
>
> http://tinyurl.com/epjqc
>[color=green]
>> You can stop looking: datetime doesn't
>> support any kind of conversion from string.
>> The number of bottomless pits in any datetime
>> module is unbounded, and Guido declared this
>> particular pit out-of-bounds at the start so
>> that there was a fighting chance to get
>> *anything* done for 2.3.[/color]
>
> I can understand why datetime can't handle
> arbitrary string inputs, but why not just
> simple iso8601 format -- i.e. the default
> output format for datetime?
>
> Given a datetime-generated string:
>[color=green][color=darkred]
> >>> now = str(datetime.da tetime.now())
> >>> print now[/color][/color]
> '2006-02-23 11:03:36.762172 '
>
> Why can't we have a function to accept it
> as string input and return a datetime object?
>
> datetime.parse_ iso8601(now)
>
> Jeff Bauer
> Rubicon, Inc.
>[/color]

[Sybren Stuvel]

Re: datetime iso8601 string input

aurora enlightened us with:[color=blue]
> I agree. I just keep rewriting the parse method again and again.[/color]

I just use the parser from mx.DateTime. Works like a charm, and can
even guess the used format.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[skip@pobox.com]

Re: datetime iso8601 string input


aurora> I agree. I just keep rewriting the parse method again and again.

aurora> def parse_iso8601_d ate(s):
aurora> """ Parse date in iso8601 format e.g. 2003-09-15T10:34:54 and
aurora> returns a datetime object.
aurora> """
...

Why not

dt = datetime.dateti me(*time.strpti me(s, "%Y-%m-%dT%H:%M:%S")[0:6])

?

Skip

[Magnus Lycka]

Re: datetime iso8601 string input

skip@pobox.com wrote:[color=blue]
> Why not
>
> dt = datetime.dateti me(*time.strpti me(s, "%Y-%m-%dT%H:%M:%S")[0:6])
>
> ?[/color]

Maybe due to neglection of the 7th commandment?
Most of the other commandments can be ignored while
coding Python, but the 7th certainly applies here.

http://www.lysator.liu.se/c/ten-commandments.html

As I've written before, the ISO 8601 spec contains
many variations in date formats. Making a full ISO
8601 parser is probably possible if we ignore time
deltas, but it's hardly worth the effort. Writing
something that parses a few percent of the possible
ISO 8601 messages and calling that an ISO 8601
parser seems silly to me.

With code like Skip's above it's obvious what kind
of strings are handled. In typical applications, one
such format is enough, and this needs to be properly
specified. In a recent case I wrote the spec like
this:

"The timestamp shall be an ISO 8601 combination of
UTC date and time with complete representation in
extended format, with representation of fractions
of seconds with up to six decimals preceeded by a
full stop as decimal sign.
E.g. 2005-06-20T13:42:55.242 5Z"

Despite my verbosity here, someone who didn't follow
the example, would still be able to write ISO 8601
strings following the requirements above that we
won't parse, since I didn't actually write that dates
should be written as year-month-day.

For a brief summary of some of the allowed variation
see http://hydracen.com/dx/iso8601.htm

[Ben Finney]

Re: datetime iso8601 string input

Magnus Lycka <lycka@carmen.s e> writes:
[color=blue]
> As I've written before, the ISO 8601 spec contains many variations
> in date formats. Making a full ISO 8601 parser is probably possible
> if we ignore time deltas, but it's hardly worth the effort. Writing
> something that parses a few percent of the possible ISO 8601
> messages and calling that an ISO 8601 parser seems silly to me.[/color]

The abundance of formats specified by ISO 8601 is indeed a barrier to
simple implementation of ISO-8601-consuming methods.

In response to this, the IETF have made RFC 3339:

"This document defines a date and time format for use in Internet
protocols that is a profile of the ISO 8601 standard for
representation of dates and times using the Gregorian calendar."
<URL:http://www.ietf.org/rfc/rfc3339.txt>

By "profile", the document essentially means a much more limited
subset of the myriad formats in ISO 8601, precisely to allow simple
conversion of timestamps to and from the format.

Could this be a candidate for a "default" consumption format for
date-time strings?

--
\ "It is well to remember that the entire universe, with one |
`\ trifling exception, is composed of others." -- John Andrew |
_o__) Holmes |
Ben Finney

[Rubic]

Re: datetime iso8601 string input

> Could [RFC 3339] be a candidate for a "default" consumption[color=blue]
> format for date-time strings?[/color]

+1