myusuf3/delorean

Delorean: Time Travel Made Easy

delorean's Issues

Feature request: interface for `next_day` should match other `next_*`/`last_*` methods.

In [90]: d.next_second()
Out[90]: Delorean(datetime=2014-03-01 05:00:01+00:00, timezone=utc)

In [91]: d.next_minute()
Out[91]: Delorean(datetime=2014-03-01 05:01:00+00:00, timezone=utc)

In [92]: d.next_day()
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-92-da50f63ce2d4> in <module>()
----> 1 d.next_day()

TypeError: next_day() takes exactly 2 arguments (1 given)

In [93]: d.last_second()
Out[93]: Delorean(datetime=2014-03-01 04:59:59+00:00, timezone=utc)

In [94]: d.last_day()
Out[94]: Delorean(datetime=2014-02-28 05:00:00+00:00, timezone=utc)

add last second method to get the previous second.

This becomes extremely useful when trying to get the last second of the day, or maybe come up with a generic way to get this.

Feature Request: Adding a `replace` method to replace parts on the underlying `datetime` object

I was wondering if we could have a feature where we could replace the parts of the underlying datetime object. For example, I would really love to do this:

d = Delorean(timezone="US/Eastern")
d = d.replace(hour=8, minute=10)

I am currently achieving this by doing this:

d = Delorean(timezone="US/Eastern")
dt = d.datetime.replace(hour=12)
d = Delorean(dt)

But the above would be much easier. I can send a PR if this seems like a good idea.

Mac '.DS_Store' file present in Dolorean/tests

I'm sure it's not a package file, but rather just an artifact from the initial commits.

Adding functionality with start_of_* and end_of_*

Hey, Yusuf!
You did a great job with this lib!

Have you thought about extending current functionality of start_of_day and end_of_day in same manner as next_* and last_*?

I was looking for a convenient way to get last day of previous month and I haven't found any.
Example of what I'm talking about:
>>> print Delorean().last_month().end_of_month()
Delorean(datetime=datetime.datetime(2016, 3, 31, 23, 59, 59, 999999), timezone='UTC')

Thanks!

Issues Handling Parse of iso8601 datetime strings

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)

Comparing Delorean objects returns incorrect results

Comparing two Delorean objects returns incorrect results:

>>> ends = Delorean(datetime.datetime(2013,4,21,16,00,00),timezone="UTC")
>>> now = Delorean()
>>> print now;print ends
Delorean(datetime=2013-04-21 15:24:15.599940+00:00, timezone=UTC)
Delorean(datetime=2013-04-21 16:00:00+00:00, timezone=UTC)
>>> now < ends
False
>>> now.epoch() < ends.epoch()
True

I suppose the bigger issue here is that it even does it rather than complain that it is not implemented.

Python 3.4 support?

Hi,

Is there a reason why the 0.4.3 version does not have the 'Programming Language :: Python :: 3.3' and 'Programming Language :: Python :: 3.4'?
It is included in the travis ci tests. For Python 3.4:

>| python -V
Python 3.4.2

I cloned the repo and did:

>| python setup.py develop
>| python tests/test_data.py

The result was:

...tests/test_data.py:431: DeprecationWarning: Please use assertEqual instead.
 self.assertEquals(dt1, dt2)
.........................................................
----------------------------------------------------------------------
Ran 60 tests in 0.016s

OK

Thanks a lot!
(Love this package).

Cut a release with arithmetic fixes?

I'm curious if you could make a PyPI version update with those changes from a couple weeks (months?) ago. It would be quite beneficial to me...

parser failling in RFC3339 format

Im using google calendar API.

See the following example:

from delorean import parse
import dateutil.parser

#event from google calendar API:
event_str
>>>  '2016-07-01T11:00:00+02:00'  #This is July 1st 2016

#delorean parse swaps months and days
parse(event_str)
>>> Delorean(datetime=datetime.datetime(2016, 1, 7, 11, 0), timezone=pytz.FixedOffset(120)) 

#dateutil parser works fine
dateutil.parser.parse(event_str)
datetime.datetime(2016, 7, 1, 11, 0, tzinfo=tzoffset(None, 7200))

Parsing string then converting to midnight and epoch.

I'm trying to parse a string row[15] using the parse function, and then convert the result to midnight, and then convert that to epoch, however it keeps coming back with:

TypeError: 'datetime.datetime' object is not callable

What am I doing wrong, and is it possible to do the above? Ideally i'd like to be able to get it to show milliseconds too...

Don't store timezone as tzinfo.tzname

This causes problems when using last_* methods off the Delorean, for example:

>>> import pytz
>>> from delorean import Delorean
>>> from datetime import datetime, timedelta
>>> pdt = pytz.timezone('America/Los_Angeles')
>>> dt = datetime.utcnow()
>>> dt = pdt.normalize(pytz.utc.localize(dt))
>>> delorean = Delorean(datetime=dt)
>>> delorean.last_week()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/blue/git/wakatime/venv/local/lib/python2.7/site-packages/delorean/dates.py", line 267, in _shift_date
    return Delorean(datetime=dt.replace(tzinfo=None), timezone=self._tz)
  File "/home/blue/git/wakatime/venv/local/lib/python2.7/site-packages/delorean/dates.py", line 198, in __init__
    self._dt = localize(datetime, timezone)
  File "/home/blue/git/wakatime/venv/local/lib/python2.7/site-packages/delorean/dates.py", line 141, in localize
    tz = timezone(tz)
  File "/home/blue/git/wakatime/venv/local/lib/python2.7/site-packages/pytz/__init__.py", line 182, in timezone
    raise UnknownTimeZoneError(zone)
pytz.exceptions.UnknownTimeZoneError: 'PDT'

PR for monkey patching

Hello,

I've been using a similar in-house module for time travel testing in Python, with the exception that mine supports monkey patching but not timezones. Monkey patching for me is absolutely vital, because many of the libraries used (e.g. Django) cannot be passed a context of custom time/datetime at runtime. For example;

period1 = datetime.datetime(2011, 1, 1)
with timetravel(period1):
    Model.objects.get_or_create() # this is created at 2013-01-01 00:00:00
    time.sleep(10)
    Model.objects.get_or_create() # this is created at 2013-01-01 00:00:10
    time.sleep(10)

Model.objects.get_or_create() # this is created at 2013-12-10 00:00:20

Although monkey patching does have a few surprising side effects when using automatic h:m:s calculation (i.e. accidental backwards time travel), it is exceptionally useful for testing time sensitive logic (such as subscription renewals etc).

It would make more sense for me to add monkey patching support onto an existing library with good maturity and py3 support, as our in-house one lacks maturity in this area.

Would you be happy for me to send a PR with a monkey patcher? Something like this;

from delorean import monkey_patch
monkey_patch()

with Delorean(datetime=dt, global=True):
   # builtins are monkey patched

with Delorean(datetime=dt) as dt:
   # builtins are not monkey patched

Let me know your thoughts

Inconsistent naming in Readme

I noticed that sometimes delorean is used, and sometimes delorian is used. Any reason?

parse method does not allow specifying timezone

It would be useful if the parse method allowed specifying a timezone.

For example, I'm trying to parse datetime strings from iostat output. They look like this:

08/18/15 16:51:36

Note that there is no timezone information specified. However, I know the timezone based on the timezone of the host system.

Hence, it would be nice if I could use Delorean's parse method, whilst also specifying a timezone. For example:

Delorean.parse('08/18/15 16:51:36', timezone='US/Pacific')

Delorean.now() accepts timezone while delorean.now() does not

The title says it all. This comes as a bit of a surprise and should be fixed, IMHO:

>>> import delorean
>>> delorean.Delorean.now(timezone='UTC')
Delorean(datetime=datetime.datetime(2016, 5, 21, 20, 44, 2, 572950), timezone='UTC')
>>> delorean.now(timezone='UTC')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: now() got an unexpected keyword argument 'timezone'

Delorean#epoch naming

Wouldn't it make more sense to name the epoch property (and function of the delorean module) something like timestamp, since the epoch will always be the beginning of 1970? To me, the name doesn't really make sense...

Tzinfo

Hi everyone I am trying to use the stops feature in my code like this:

         count = 0

        for stop in stops(freq=delorean.DAILY, count=7, start=d1, stop=d2):
            if(stop.date == mydate):
                count = count + 1

But I keep getting this error:

AttributeError: 'datetime.date' object has no attribute 'tzinfo'

I dont understand what I am doing wrong. Will really appreciate the help.

Best

Stops bug

The stops function is not working properly, reviewing the code I've found a mistake, the parameters of stops function aren't passed to the rrule so.

DST issue

I found an issue with DST, which bugged me today 😬

In [25]: Delorean().datetime.timetuple()
Out[25]: time.struct_time(tm_year=2014, tm_mon=4, tm_mday=2, tm_hour=9, tm_min=45, tm_sec=32, tm_wday=2, tm_yday=92, tm_isdst=0)
In [26]: datetime.datetime.utcnow().timetuple()
Out[26]: time.struct_time(tm_year=2014, tm_mon=4, tm_mday=2, tm_hour=9, tm_min=47, tm_sec=23, tm_wday=2, tm_yday=92, tm_isdst=-1)

As you can see, the tm_isdst is wrongly defaulted to 0 by Delorean. As the documentation states:

A -1 argument as the daylight savings flag, passed to mktime() will usually result in the correct daylight savings state to be filled in.

And

Because of this, it is platform-specific except for recognizing UTC and GMT which are always known (and are considered to be non-daylight savings timezones).

I'm not sure whether this is a bug or a feature, but the problem in this case is, that when we convert both timetuples to a unix timestamp, we are off by an hour:

In [11]: time.mktime(datetime.datetime.utcnow().timetuple()) - time.mktime(Delorean().datetime.timetuple())
Out[11]: -3600.0

I'll see if I can pinpoint the issue and create a pull request.

Error handling fractional seconds?

It's possible I'm missing something here, but it seems like Delorean doesn't handle fractional seconds correctly in the next_second/last_second methods:

In [115]: dt
Out[115]: datetime.datetime(2015, 1, 1, 0, 0)

In [116]: d = Delorean(dt, timezone='utc')

In [117]: d.next_second(0.5).datetime
Out[117]: datetime.datetime(2015, 1, 1, 0, 0, tzinfo=<UTC>)

In [118]: _.microsecond
Out[118]: 0

In [119]: dt + relativedelta(seconds=0.5)
Out[119]: datetime.datetime(2015, 1, 1, 0, 0, 0, 500000)

Fractional days do seem to work:

In [124]: d.next_day(0.7390)
Out[124]: Delorean(datetime=2015-01-01 17:44:09.600000+00:00, timezone=utc)

BTW, really enjoying the package so far, it's made the code I've been writing an order of magnitude better.

Documentation mismatch for parsing strings in latest version

Theres a bug when parsing date strings in the latest release.

In a new virtual env:

$ pip install delorean
$ pip freeze
Babel==2.2.0
Delorean==0.6.0
humanize==0.5.1
python-dateutil==2.5.2
pytz==2016.3
six==1.10.0
tzlocal==1.2.2
wheel==0.24.0

>>> import delorean
>>> delorean.parse("2013-05-06")
Delorean(datetime=datetime.datetime(2013, 6, 5, 0, 0), timezone='UTC')

but the docs say that the output should be Delorean(datetime=datetime.datetime(2013, 5, 6), timezone='UTC') (which is the correct thing to do according to ISO 8601).

Installing python-dateutil==2.5.1 fixes the problem, but i'm not sure if the bug is in delorean or on their end.

Strict ISO 8601 parser

There are times when you want to enforce a standard format. Any interest in adding a parse_iso8601 to the library? Can simply delegate to iso8601 or have a new implementation if you don't want to import another lib.

I can send out a PR if you're OK with this.

dateutil >= 2.1

Is it possible to change the req for python-dateutils from ==2.1 to >= 2.1?

Causing me some conflicts. It appears to work with 2.2

issues brought up by @wardi

[11:06:22] <wardi>   this is the case where your dt is the 31st of the month and you move it to a month without 31 days
[11:06:48] <wardi>   you might want to choose the last day of the month, or maybe the first day of the next month
[11:07:14] <wardi>   or maybe you want it to raise an exception so you can do something else
[11:08:49] <wardi>   as an aside there is also the concept of 'last working day of the month' or 'second tuesday of the month'
[11:54:51]   Pwnna ([email protected]) joined the channel.
[12:08:24] <wardi>   wrt this policy, I think you should make the user choose.  Failing that *at least* you need to document which behaviour delorean has
[12:13:36] <wardi>   personally, I would prefer to use a library that forced me to think carefully about the behaviour I want, instead of quietly making choices for me
[12:14:37] <wardi>   you could have a policy object that you pass to Delorean(), with some sensible default policy.  That would be like the decimal stdlib module
[12:16:00] <wardi>   then you keep an easy api, and clear documentation of which choices are made and a sane way to change the behaviour if you need to
[12:16:49] <wardi>   it's something you could add in a later version if you just document the choices Delorean makes currently

Error parsing when current day is not in month

Hi,

Since delorean.parse() fills missing info from the string with the current date, it will fail if trying to parse a date with month if your current day is out of that month.
An example to make it clear:

1. Today is 30th September
2. I do `delorean.parse('2000-02')``
3. I will get "Unknown string format" since 30th does not exist for February

What would be the correct approach to parse this kind of strings? Is there a way to parse without filling the missing information with the current date (for example with day 1, hour 0 etc)?

Add end_of_day method

The end of day method will set the time to 23:59:59.

Add a wrapper for babel's parse_pattern()

Sometimes you want more control over the parsing process than the heuristic of dateutil's parse function can give you or you have really weird strings. Since babel is already used for formatting the output, it would be quite handy to also have the parse_pattern() function available: http://babel.pocoo.org/en/latest/api/dates.html#babel.dates.parse_pattern It accepts the same patterns and also a locale.

I could provide a pull request if this is deemed useful.

PyPi / repo code is different

I installed delorean using pip, which reports Delorean==0.2.1, which appears to be the same as the repo's version.py (0,2,1).

However, the PyPi version of dates.py is missing several of the functions found in the repo (e.g. move_datetime_hour, move_datetime_minute, move_datetime_second).

I'm assuming this means the repo was updated at some point, but PyPi wasn't and the repo's version.py didn't get bumped up.

get_total_second() docstring formatting problem

See http://delorean.readthedocs.org/en/latest/interface.html#delorean.dates.get_total_second
Sphinx is hyperlinking the ** (to a nonexistent #id1) for some reason.

moar parser testing

Open discussion

Hi all,

I recently stumbled on this library for the 2nd time through PyCoders Weekly and decided to check it out. I've been trying to pick up some low hanging fruit while getting familiar with the source, and I hope the small contributions I've made so far are helpful. As I've been familiarizing myself with Delorean and other datetime replacements I've found a few unanswered questions. It would be great to have a discussion around them.

• What are the biggest needs for this project?
• How does this project distinguish itself from other datetime replacements like arrow and moment?

Thanks!

Get Range for Specific Interval

Is there a way with Delorean stops to return date intervals between a start and stop date? For example, if I set start date to 2013-06-01 and end date to 2013-06-08 and I'd like the stop to return a date range of 7 days it should return the date range 2013-06-01 to 2013-06-07 and then just the single date of 2013-06-08.

python_dateutil 2.5.2 breaks parsing

It seems that recently (3/27) there was a new version of python_dateutil released (2.5.2) that breaks parsing of strings. I'm able to work around this by pinning python_dateutil to 2.5.1.

>>> from delorean import parse
>>> parse("2015-11-25T07:24:40.504024+0000")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/appenv/local/lib/python2.7/site-packages/delorean/interface.py", line 68, in parse
    dt = capture(datetime_str, dayfirst=dayfirst, yearfirst=yearfirst)
  File "/appenv/local/lib/python2.7/site-packages/dateutil/parser.py", line 1164, in parse
    return DEFAULTPARSER.parse(timestr, **kwargs)
  File "/appenv/local/lib/python2.7/site-packages/dateutil/parser.py", line 577, in parse
    ret = default.replace(**repl)
ValueError: month must be in 1..12
>>> parse("2015-25-11T07:24:40.504024+0000")
Delorean(datetime=datetime.datetime(2015, 11, 25, 7, 24, 40, 504024), timezone='UTC')

Breaking interface by returning pytz objects

Trying to parse a string and get its timezone returns a pytz object.

>>> type(delorean.parse('2016-02-10T14:32:44.773558').timezone)
<class 'pytz.UTC'>

I think Delorean shouldn't expose its implementation by returning objects from its dependencies like that. Also think I shouldn't have to import pytz in order to compare it against the Delorean object.

I'd be fine with just being able to do from delorean import utc or even from delorean import timezone; utc = timezone('UTC')

Variable Interpolation changes the result of Delorean functions

Right, so I've just uploaded about 26,000 notes via this HubSpot endpoint, and i've noticed that a bunch of the uploaded notes have very wrong timestamps (for example instead of being back-dated, or up-to-date, they're flung far into the future).

I've traced the issue back to a portion of my code which uses Delorean to make it easier to parse and convert times to epoch timestamps. The issue seems to be that, when I use variable interpolation via the .format() function - it seems to somehow change something.

Example 1 - No interpolation.

def ref_date_epoch():
        parseDate = parse("29/04/2014 00:00:00 -0700")
        getEpoch = parseDate.epoch
        shiftEpoch = epoch(getEpoch).shift("US/Eastern")
        convertEpoch = shiftEpoch.epoch
        testing = int(convertEpoch)
        return "{testing}000".format(testing=testing)

print(ref_date_epoch())
sys.exit()

The above example returns 1398754800000 as the epoch timestamp, which will convert into the correct date - 29/04/2014.

Example 2 - With interpolation.

def ref_date_epoch(datestr):
    if len(datestr) > 0:
        parseDate = parse("{csvDate} 00:00:00 -0700".format(csvDate=datestr))
        getEpoch = parseDate.epoch
        shiftEpoch = epoch(getEpoch).shift("US/Eastern")
        convertEpoch = shiftEpoch.epoch
        testing = int(convertEpoch)
        return "{testing}000".format(testing=testing)
    else:
        None

print(ref_date_epoch(row[2]))
sys.exit()

This time, the above example returns 1597302000000 as the epoch timestamp, which is really, really wrong - it ends up being 13/08/2020. To elaborate, the datestr argument is accepting the list row[2] which references the index of a row in a csv which contains the date.

Example 3. Without the .format() function:

def ref_date_epoch(datestr):
    if len(datestr) > 0:
        parseDate = parse(datestr)
        getEpoch = parseDate.epoch
        shiftEpoch = epoch(getEpoch).shift("US/Eastern")
        convertEpoch = shiftEpoch.epoch
        testing = int(convertEpoch)
        return "{testing}000".format(testing=testing)
    else:
        None

print(ref_date_epoch(row[2]))
sys.exit()

This still returns 1597276800000. It seems that the mere act of indirectly referencing the date seems to change the time. What gives?

epoch issue?

In [57]: Delorean(datetime.now(), timezone='UTC').epoch() - time.time()
Out[57]: 7199.999927997589

In [58]: time.mktime(Delorean(datetime.now(), timezone='UTC').datetime.timetuple()) - time.time()
Out[58]: 3599.633516073227

Return value from __repr__ should be callable in eval()

It is common Python practice to make the string value returned from the repr method evaluatable. For instance, I should be able to do the following:

>>> d1 = Delorean(datetime(2015, 1, 1), timezone='UTC')
>>> d2 = eval(repr(d1))
>>> d1 == d2
True

The current implementation raises a SyntaxError.

>>> d1 = Delorean(datetime(2015, 1, 1), timezone='UTC')
>>> d2 = eval(repr(d1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    Delorean(datetime=2015-01-01 00:00:00+00:00, timezone=UTC)
                                  ^
SyntaxError: invalid syntax

end_of_day returns the middle of the day

Current:

>>> Delorean(datetime(2015, 1, 1), timezone='UTC').end_of_day()
datetime.datetime(2015, 1, 1, 11, 59, 59, 999999, tzinfo=<UTC>)

Correct:

>>> Delorean(datetime(2015, 1, 1), timezone='UTC').end_of_day()
datetime.datetime(2015, 1, 1, 23, 59, 59, 999999, tzinfo=<UTC>)

Your datetime readme example is broken

as discussed here:

http://stackoverflow.com/questions/31886808/when-does-datetime-nowpytz-timezone-fail

Effective code:

d = datetime.utcnow()
utc = timezone(UTC)
est = timezone(EST)
d = utc.localize(d)
d = est.normalize(EST)
return d

becomes:

est = timezone(EST)
d = est.normalize(EST)
return d

becomes:

return timezone(EST).normalize(EST)

__eq__ should return True for datetimes that are UTC equal

Delorean should know if two times are UTC equal. The following code will return False:

>>> d1 = Delorean(datetime(2015, 1, 1), timezone='US/Pacific')
>>> d2 = Delorean(datetime(2015, 1, 1, 8), timezone='UTC')
>>> d1 == d2
False

The two times are actually equivalent, so it seems like the above code should return True. Maybe this is working as intended, but I was unable to find any documentation supporting that decision.

Delorean support for timedelta arithmetic

The timedelta class in the datetime package is very useful for calendar/time arithmetic. It would be great if Deloreans had the same behavior as datetime objects:

from datetime import timedelta, datetime
from delorean import Delorean

dd1 = Delorean(datetime(2013, 2, 15), "US/Eastern")
dd2 = Delorean(datetime(2013, 2, 16), "US/Eastern")

one_day = dd2 - dd1
assert one_day == timedelta(days=1)
assert (dd1 + one_day) == dd2

Python 3 support?

Hi. I would love to use this in my python3 applications but it currently will not work.
Any plans to support it officialy?

Delorean object from aware datetimes

There seems to be no way to create a Delorean object from an aware datetime object.

Is there a reason for this?

I tend to work with fully aware datetime objects in UTC, but with them being passed around and used everywhere, it's not particularly easy to create a Delorean object from them, without having to do:

dt = Delorean(datetime=dt_utc.replace(tzinfo=None), timezone='UTC')

Which is a bit tedious for an awesome library like Delorean!

I might be a little naive though (excuse the pun!) so I wanted to ask!

windows and the epoch method

TODO

Support for when only time zone UTC offsets are known

I'm having to handle time zones where I only know the UTC offset and no specific time zone identifier string. I'd still like to be able to plug in these into Delorean as my app is already built around Delorean because of it's awesomeness!

I'm generating tzinfo objects using pytz's (rather hidden) FixedOffset class, but as there is no standard for naming such offsets, there's no way for me to plug them in to Delorean.

So it would be awesome if I could either pass tzinfo objects straight into any timezone argument, or whether Delorean could parse certain strings (perhaps in the ISO 8601 UTC time offset format i.e. ±hh:mm, ±hhmm, ±hh) and then Delorean could create tzinfo objects from those using the FixedOffset class or similar.

Would be great to hear your thoughts.

end_of_day does not handle leap seconds

Leap seconds occaisonally get added to days to account for the Earth's slowing rotation. The end_of_day function should be aware of days that contain leap seconds, and return the proper value accordingly.

>>> d = Delorean(datetime(2015, 6, 30), timezone='US/Pacific')
>>> d.end_of_day()
datetime.datetime(2015, 6, 30, 23, 59, 60, 999999, tzinfo=<DstTzInfo 'US/Pacific' PDT-1 day, 17:00:00 DST>)

Misplaced word in "Ambiguous cases" section of docs

See http://delorean.readthedocs.org/en/latest/quickstart.html#ambiguous-cases
There seems to be a misplaced instance of the word "precedence" at the start of one of the lines:

precedence`Delorean` makes the assumptions that ``dayfirst=True`` and ``yearfirst=True`` this will lead to the following precedence.

Two unit tests are failing: test_naive_timezone and testparse_with_timezone

When I run the unit tests (via "make test"), two of the unit tests fail.

Python version: 2.7.3

I had just cloned the repo and I have not had a chance to play around with the code base so its possible that I am missing something basic.

I can import the two dependencies (pytz and python-dateutil).

I am in the master branch and the latest commit was on Mon Jan 21 02:09:06 2013 -0500 (commit: f267a0e)

----- Traceback for failing unit tests -----

FAIL: test_naive_timezone (main.DeloreanTests)

Traceback (most recent call last):
File "tests/test_data.py", line 86, in test_naive_timezone
self.assertEqual(dt2, dt1)
AssertionError: datetime.datetime(2013, 1, 22, 0, 49, 59) != datetime.datetime(2013, 1, 21, 19, 49, 59)

FAIL: testparse_with_timezone (main.DeloreanTests)

Traceback (most recent call last):
File "tests/test_data.py", line 328, in testparse_with_timezone
self.assertEqual(d2, d1.datetime)
AssertionError: datetime.datetime(2011, 1, 1, 7, 0, tzinfo=) != datetime.datetime(2011, 1, 1, 0, 0, tzinfo=)

---

Ran 41 tests in 0.005s

FAILED (failures=2)

Fix midnight() and naive() references on Quickstart page

The overview mentions that

• Delorean.epoch is a property, not a function.
• Delorean.midnight is a property, not a function.
• Delorean.naive is a property, not a function.
• Delorean.timezone is a property, not a function.

but the quickstart page still has examples showing midnight() and naive()