dateutil.parser
will attach a time zone if and only if it finds one, which could depend on your local machine time zone settings, because if it detects an abbreviated time zone like "EST" that is in the list of abbreviations for your local time zone, it will assume that that's the one you mean.
That said, this is not what is happening in this case. Even if parser
were attaching a time zone, datetime.replace
does a wholesale replacement of the time zone, not a conversion. I do not think there is enough information in your question to fully diagnose this issue, but if timezone()
is pytz.timezone()
, at least one of your issues is that pytz
time zones can't be attached to datetime
objects with replace
. You would need to instead use datetime_obj = pytz.timezone(tz_code).localize(datetime_obj)
.
Note that the localize
method assumes that you have a timezone-naive object, so it will throw an error if datetutil
's parser returns a timezone-aware datetime
, so you should pass ignoretz=True
to the parser to prevent this.
That said, even once you do this, the real issue is in your use of time.mktime
. See this answer, which is exactly the same problem. To summarize that answer, the best thing to do is to use calendar.timegm
instead of mktime
, and convert to UTC before calling it. Incorporating my suggestions, here is an updated version of your code:
import calendar
from dateutil.tz import tzutc
def parse_date(datetime_string, tz_code):
tz = timezone(tz_code)
datetime_obj = parser.parse(datetime_string, ignoretz=True)
datetime_obj_localized = tz.localize(datetime_obj)
datetime_obj_utc = datetime_obj_localized.astimezone(tzutc())
return calendar.timegm(datetime_obj_utc.timetuple())