Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues Handling Parse of iso8601 datetime strings #53

Open
myusuf3 opened this issue Feb 4, 2015 · 2 comments
Open

Issues Handling Parse of iso8601 datetime strings #53

myusuf3 opened this issue Feb 4, 2015 · 2 comments

Comments

@myusuf3
Copy link
Owner

myusuf3 commented Feb 4, 2015

GOOD (precise offset): '2015-02-04T16:33:21.247513-05:00'
GOOD (precise utc indication): '2013-09-30T15:34:00.000Z'
BAD (no offset): '2015-02-04T16:33:21.247513'

Currently delorean parse function casts the bad (no timezone) version of the to utc.

Although there is no way to know whether or not the UTC was provided like in the 2nd good option or it was a decision (assumption) made my delorean internally (I blame my OCD).

Give a way to introspect this would be ideal. I would like to avoid providing naive datetimes being return by delorean but maybe a way to determine if assumptions were made.

Like so currently

>>> parse('2015-02-04T16:33:21.247513')
Delorean(datetime=2015-02-04 16:33:21.247513+00:00, timezone=UTC)
>>> parse('2015-02-04T16:33:21.247513').naive()
datetime.datetime(2015, 2, 4, 16, 33, 21, 247513)

Maybe this

>>>parse('2015-02-04T16:33:21.247513')
(True,Delorean(datetime=2015-02-04 16:33:21.247513+00:00, timezone=UTC))
>>> assumed, datetime = parse('2015-02-04T16:33:21.247513').naive()
>>> datetime
datetime.datetime(2015, 2, 4, 16, 33, 21, 247513)
@myusuf3
Copy link
Owner Author

myusuf3 commented Feb 4, 2015

@rwarren Thoughts?

@rwarren
Copy link

rwarren commented Feb 5, 2015

Not a fan of the tuple return. I think I have a solution that enables me to not have to venture outside of the delorean for handling naive times, though. It works like this:

>>> from delorean import parse
>>>
>>> # Offset specified normalizes to UTC...
>>> parse("2015-02-04T16:33:21.247513-05:00")
Delorean(datetime=2015-02-04 21:33:21.247513+00:00, timezone=UTC)
>>>
>>> # UTC explicitly stated (with Z suffix) is also directly UTC...
>>> parse("2015-02-04T21:33:21.247513Z")
Delorean(datetime=2015-02-04 21:33:21.247513+00:00, timezone=UTC)
>>>
>>> # default behaviour with parse of naive times stays status quo (norm to UTC)...
>>> parse("2015-02-04T21:33:21.247513")
Delorean(datetime=2015-02-04 21:33:21.247513+00:00, timezone=UTC)
>>>
>>> # ...unless you *tell* delorean to keep it naive (note datetime return)...
>>> parse("2015-02-04T21:33:21.247513", naivemode="naive")
datetime.datetime(2015, 2, 4, 21, 33, 21, 247513)
>>>
>>> # ... or you can (of course) explicitly state the default behaviour (norm to utc)...
>>> parse("2015-02-04T21:33:21.247513", naivemode="utc")
Delorean(datetime=2015-02-04 21:33:21.247513+00:00, timezone=UTC)
>>>
>>> # ...or you can tell it to bark at naive times...
>>> parse("2015-02-04T21:33:21.247513", naivemode="raise")   #BAD
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "delorean/interface.py", line 52, in parse
    raise DeloreanInvalidDatetime("Unable to determine timezone info")
DeloreanInvalidDatetime: Unable to determine timezone info

What do you think? This is up and working. I'll send a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants