Delorean: Time Travel Made Easy

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!

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.

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

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...

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).

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

shift() currently mutates the original Delorean object, so this is just a simple way to get a copy of the current object with an optional new timezone.

Thank you for cool library.

In some of versions between 2.5 and 2.6 python-dateutil broke ISO date parsing when dayfirst=True. Unfortunately, delorean uses True for this parameter by default. So, I've fixed it:

1. Try to parse string as ISO date before everything else.
2. You can disable it via isofirst=False.
3. Added test for this case.
4. python-dateutil version constraint now >=2.7.0, because dateutil.parser.isoparse added only in this version.

Close #101

To reproduce:

import delorean
import datetime

utc = datetime.timezone.utc
dt = datetime.datetime(2017, 3, 5, 3, 1, 46, 425154, tzinfo=utc)

d = delorean.Delorean(dt).shift(utc)

From these lines, Delorean doesn't support anything outside of pytz.timezone ability to parse, which breaks on zone.upper() at the beginning of this method.

Should I always use "UTC" instead of datetime's provided datetime.timezone.utc? I was hoping to reuse the standard library's version across different datetime libraries.

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.

If a user is trying to convert a datetime initialized with a pytz tzinfo to Delorean the following happens:

a = datetime(2013,8,13,7,3,26,56569, tzinfo=pytz.UTC)
>>> delorean.Delorean(a)
Delorean(datetime=2013-08-13 07:03:26.056569+00:00, timezone=UTC)

But if a user is trying to convert a datetime initialized with a non-pytz tzinfo to Delorean the following happens:

>>> b = datetime(2013,8,13,7,3,26,56569, tzinfo=colander.iso8601.UTC)
delorean.Delorean(b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/dev/.virtualenvs/whatstolose/local/lib/python2.7/site-packages/delorean/dates.py", line 169, in __init__
    zone = datetime.tzinfo.zone
AttributeError: 'Utc' object has no attribute 'zone'

Here are the docs for the tzinfo objects and the methods it should have: http://docs.python.org/release/2.5.2/lib/datetime-tzinfo.html

The change I've made should now allow delorean to work with any TZ aware datetime.

There are small typos in:

• delorean/dates.py
• delorean/interface.py
• docs/install.rst
• docs/quickstart.rst

Fixes:

• Should read specifically rather than specifcally.
• Should read posed rather than possed.
• Should read delorean rather than delorian.
• Should read convenient rather than convient.
• Should read associated rather than assoicated.
• Should read associated rather than assocaited.

Semi-automated pull request generated by https://github.com/timgates42/meticulous/blob/master/docs/NOTE.md

Environment:

• Python 3.9.2
• pytz 2021.3

When using delorean.parse() this warning message is produced:

delorean/dates.py:170: PytzUsageWarning: The normalize method is no longer necessary, as this time zone supports the fold attribute (PEP 495). For more details on migrating to a PEP 495-compliant implementation, see https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html

I'm running into an error when using Delorean within a Django app context. This only happens when the Django app is loaded. For example, in the interpreter setup by django:

$ python manage.py shell
Python 3.9.6 (default, Jun 29 2021, 05:25:02) 
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> t = '2020-11-30T05:17:05.000000Z'
>>> import delorean
>>> delorean.parse(t).datetime

This results in:

Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File ".../lib/python3.9/site-packages/delorean/interface.py", line 87, in parse
    do = Delorean(dt, timezone=tz)
  File ".../lib/python3.9/site-packages/delorean/dates.py", line 202, in __init__
    self._dt = localize(datetime, self._tzinfo)
  File ".../lib/python3.9/site-packages/delorean/dates.py", line 157, in localize
    return tz.localize(dt)
AttributeError: 'zoneinfo.ZoneInfo' object has no attribute 'localize'

The same procedure done outside of django results in a successful parsing of the datetime.

$ python
Python 3.9.6 (default, Jun 29 2021, 05:25:02) 
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> t = '2020-11-30T05:17:05.000000Z'
>>> import delorean
>>> delorean.parse(t).datetime
datetime.datetime(2020, 11, 30, 5, 17, 5, tzinfo=<UTC>)

Note, it's the same environment, just not within the django shell setup.

AFAICT, the only difference is that Django is using a zoneinfo timezone instance, while pure python is finding any using a pytz timezone instance.

example shows:

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

executing the example, I get:

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

Documentation shows dayfirst=True as default, so there's nothing wrong with the code. Just the example needs fixing.

@myusuf3 Any chance of publishing a new version of Delorean to pip that includes the fix provided here: https://github.com/myusuf3/delorean/pull/103

Cheers