1

I am trying to identify the timestamp of a specific moment in time, considering a particular date and time with a particular timezone.

However, it seems that constructing that combination with datetime.combine() will give me one result, while using datetime.now().replace() will give me another one.

from datetime import datetime, time
import pytz

ny_tz = pytz.timezone('America/New_York')

datetime.combine(datetime.today(), time(15, 54, 55), tzinfo=ny_tz).timestamp()
# 1648846255.0

datetime.now(tz=ny_tz).replace(hour=15, minute=54, second=55, microsecond=0).timestamp()
# 1648842895.0

The datetime.combine() option seems to give me a timeframe that is about 56-minutes off.

What's the reason behind this difference?

Edit: As requested in the comments, the usage of pytz.timezone.localize also fails:

ny_tz.localize(datetime.combine(datetime.today(), time(15, 54, 55))).timestamp()
# 1648842895.0
Alpha
  • 7,586
  • 8
  • 59
  • 92
  • The first one gives `datetime.datetime(2022, 4, 1, 15, 54, 55, tzinfo=)`, the second one gives `datetime.datetime(2022, 4, 1, 15, 54, 55, tzinfo=)`. Can't see at first glance why this is the case – Pranav Hosangadi Apr 01 '22 at 21:20
  • 1
    It seems like the `tz` parameter in `datetime.now` isn't treated the same as `tzinfo` in `datetime.__init__()`. – Pranav Hosangadi Apr 01 '22 at 21:28
  • 1
    @PranavHosangadi it doesn't just seem like this, it ***is*** like this. `datetime.now` constructor correctly deals with pytz timezone while `datetime.combine` doesn't (it's as if you'd use `replace`, which also doesn't work with pytz timezones -> see "localize"...) – FObersteiner Apr 01 '22 at 21:41
  • @FObersteiner I haven't done much with timezones, so this was new to me. So the answer is use `tz.localize(datetime)` instead of `datetime(tzinfo=tz)`. TIL I've been using time zones wrong for the little bit of work I have done with it (although I always used `tzinfo=tz` so they were all equally wrong :) ) – Pranav Hosangadi Apr 01 '22 at 21:47
  • @FObersteiner It seems like you're really close to the source of the issue, but it rather is something new which is broken in the Python datetime module or it has been broken for a long time, which I don't think is the case, as I believe it would have been found sooner. I'll verify later if there are any python reported bugs but I think this one would warrant a quick fix. – Alpha Apr 01 '22 at 21:49
  • 2
    I found this issue with the pytz timezone to be very common, at least here on SO. Check out the [docs](http://pytz.sourceforge.net/) - it even says "This library differs from the documented Python API for tzinfo implementations" there, followed by a hint to the "localize-trap". I've just recently added some [more up-to-date and fail-safe options](https://stackoverflow.com/a/71668778/10197418) to the question I linked above. – FObersteiner Apr 01 '22 at 21:54
  • Thanks folks! I wasn't sure those related answers were the same one, but after reading the explanation and the documentation, I agree it is. Thank you for the help! – Alpha Apr 03 '22 at 16:46

0 Answers0