when does `datetime.now(pytz_timezone)` fail?

Question

delorean docs show this way to get the current time in a given timezone using datetime:

from datetime import datetime
from pytz import timezone

EST = "US/Eastern"
UTC = "UTC"

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

and compare it with the delorian-based code:

from delorean import Delorean

EST = "US/Eastern"

d = Delorean(timezone=EST)

I believe the datetime example should be written as:

from datetime import datetime
import pytz

eastern_timezone = pytz.timezone("US/Eastern")
d = datetime.now(eastern_timezone)

that is more concise.

Are there any cases when the last code example fails while the first one continues to work?

---

Update: the current example:

from datetime import datetime
import pytz

d = datetime.utcnow()
d = pytz.utc.localize(d)

est = pytz.timezone('US/Eastern')
d = est.normalize(d)
return d

that is still too verbose.

The question stills stands: do you need the explicit round-trip via utc and tz.normalize() or can you use datetime.now(tz) instead?

Answer 1

When does datetime.now(pytz_timezone) fail?

As far as I can tell, there are no scenarios where it could fail. datetime.now invokes the fromutc function on the tzinfo instance passed in the parameter. All conversions from UTC to local time are unambiguous, so there are no opportunities for failure.

Also, the original code does not even work.

d = est.normalize(EST)

This would appear to pass a string as the only parameter to normalize, which is intended to take a datetime. This gives:

AttributeError: 'str' object has no attribute 'tzinfo'

I believe they meant to write:

d = est.normalize(d.astimezone(est))

That said, I don't think the verbosity of their code adds much value. As you noted, it's just as easy to do this in a single step:

d = datetime.now(est)

Looking at the cpython source code for datetime.now, I can see that when a tzinfo object is provided, it calls the fromutc method on that object.

if (self != NULL && tz != Py_None) {
    /* Convert UTC to tzinfo's zone. */
    PyObject *temp = self;

    self = _PyObject_CallMethodId(tz, &PyId_fromutc, "O", self);
    Py_DECREF(temp);
}

Then, in the pytz source, I see that the fromutc method is implemented differently depending on whether the zone is pytz.UTC, or an instance of StaticTzInfo, or DstTzInfo. In all three cases, the transformation from the input UTC value to the target time zone is unambiguous. Here is the DstTzInfo implementation, which is the more complex of the three:

def fromutc(self, dt):
    '''See datetime.tzinfo.fromutc'''
    if (dt.tzinfo is not None
        and getattr(dt.tzinfo, '_tzinfos', None) is not self._tzinfos):
        raise ValueError('fromutc: dt.tzinfo is not self')
    dt = dt.replace(tzinfo=None)
    idx = max(0, bisect_right(self._utc_transition_times, dt) - 1)
    inf = self._transition_info[idx]
    return (dt + inf[0]).replace(tzinfo=self._tzinfos[inf])

This would appear to find the transition from _utc_transition_times of the time zone, then apply it to the returned datetime. There are no ambiguities in this direction, so the results will be equivalent.

Also worth noting, in the datetime docs it says that datetime.now is equivalent to calling:

tz.fromutc(datetime.utcnow().replace(tzinfo=tz))

Given the source of fromutc in pytz I showed earlier, I'm not sure that this is any different than just:

tz.fromutc(datetime.utcnow())

But in either case, I don't think localize and normalize are necessary.