> Could [RFC 3339] be a candidate for a "default" consumption
> format for date-time strings?
+1
--
http://mail.python.org/mailman/listinfo/python-list
Magnus Lycka <[EMAIL PROTECTED]> writes:
> 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 pos
[EMAIL PROTECTED] wrote:
> Why not
>
> dt = datetime.datetime(*time.strptime(s, "%Y-%m-%dT%H:%M:%S")[0:6])
>
> ?
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
aurora> I agree. I just keep rewriting the parse method again and again.
aurora> def parse_iso8601_date(s):
aurora> """ Parse date in iso8601 format e.g. 2003-09-15T10:34:54 and
aurora> returns a datetime object.
aurora> """
...
Why not
dt = dateti
aurora enlightened us with:
> I agree. I just keep rewriting the parse method again and again.
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 st
I agree. I just keep rewriting the parse method again and again.
wy
def parse_iso8601_date(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('Invalid
Rubic wrote:
> 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. ;-)
I think the big issue is t
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,
Rubic wrote:
> 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
> o
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
Rubic wrote:
> 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?
Have you actually read the ISO 8601 standard?
If you have, you would know that parsing valid
ISO 8601 is fairly close to h
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
> You can stop looking: datetime doesn't
> support any kind o
12 matches
Mail list logo
