Specifically, given the timezone of my server (system time perspective) and a timezone input, how do I calculate the system time as if it were in that new timezone (regardless of daylight savings, etc)?
import datetime current_time = datetime.datetime.now() #system time server_timezone = "US/Eastern" new_timezone = "US/Pacific" current_time_in_new_timezone = ???
If you know your origin timezone and the new timezone that you want to convert it to, it turns out to be very straightforward:
pytz.timezoneobjects, one for the current timezone and one for the new timezone e.g.
pytz.timezone("US/Pacific"). You can find a list of all official timezones in
import pytz; pytz.all_timezones
Localize the datetime/timestamp of interest to the current timezone e.g.
current_timezone = pytz.timezone("US/Eastern") localized_timestamp = current_timezone.localize(timestamp)
- Convert to new timezone using
.astimezone()on the newly localized datetime/timestamp from step 2 with the desired timezone’s pytz object as input e.g.
As a full example:
import datetime import pytz # a timestamp I'd like to convert my_timestamp = datetime.datetime.now() # create both timezone objects old_timezone = pytz.timezone("US/Eastern") new_timezone = pytz.timezone("US/Pacific") # two-step process localized_timestamp = old_timezone.localize(my_timestamp) new_timezone_timestamp = localized_timestamp.astimezone(new_timezone) # or alternatively, as an one-liner new_timezone_timestamp = old_timezone.localize(my_timestamp).astimezone(new_timezone)
Bonus: but if all you need is the current time in a specific timezone, you can conveniently pass that timezone directly into datetime.now() to get the current times directly:
When it comes to needing timezones conversions generally, I would strongly advise that one should store all timestamps in your database in UTC, which has no daylight savings time (DST) transition. And as a good practice, one should always choose to enable time zone support (even if your users are all in a single time zone!). This will help you avoid the DST transition problem that plagues so much software today.
Beyond DST, time in software can be generally quite tricky. To get a sense of just how difficult it is to deal with time in software in general, here is a potentially enlightening resource: http://yourcalendricalfallacyis.com
Even a seemingly simple operation as converting a datetime/timestamp into a date can become non-obvious. As this helpful documentation points out:
A datetime represents a point in time. It’s absolute: it doesn’t depend on anything. On the contrary, a date is a calendaring concept. It’s a period of time whose bounds depend on the time zone in which the date is considered. As you can see, these two concepts are fundamentally different.
Understanding this difference is a key step towards avoiding time-based bugs. Good luck.