In Python 3.x, I want to capture current time along with its timezone and then convert it into Unix timestamp and sent to a server.
I have tried various libraries like pytz, arrow, moment, pendulum, but I am not sure how to deal with daylight saving time (DST). Currently, I am using time.tzname to get timezone information but it specifically showing India in DST. In reality India never follows DST.
The library pytz should work pretty well. You need to use the function dst() from that library to check if a timezone is under daylight savings influence.
https://medium.com/#nqbao/python-timezone-and-daylight-savings-e511a0093d0
From the link above:
>>> import pytz
>>> pst = pytz.timezone("US/Pacific")
>>> pst.localize(datetime(2017, 10, 1)).dst()
datetime.timedelta(0, 3600)
>>> pst.localize(datetime(2017, 12, 1)).dst()
datetime.timedelta(0)
Understanding offset naive and offset aware date times will make your life much easier.
This helped me in resolving the issue using time.tzname
if time.tzname[1] is None or time.tzname[0] == time.tzname[1]:
timezone = time.localtime().tm_zone
# no DST
timezone = time.tzname[0]
else:
# we're in DST
timezone = time.tzname[1]
Related
I have a time string disseminated from a MQTT broker that I would like to read and convert from its native timezone (U.S. Central Time) to Coordinated Universal Time (UTC). I am currently using Python 3.8.5 in Ubuntu 20.04 Focal Fossa, with the machine timezone set to UTC.
The time string is as follows: 1636039288.815212
To work with this time in Python, I am using a combination of the datetime and pytz libraries. My current core of code is as follows:
from datetime import datetime, timedelta
import pytz
input = 1636039288.815212
srctime = datetime.fromtimestamp(input, tz=pytz.timezone('US/Central'))
After running this chunk, I receive the following undesired time output:
datetime.datetime(2021, 11, 4, 10, 21, 28, 815212, tzinfo=<DstTzInfo 'US/Central' CDT-1 day, 19:00:00 DST>)
It appears that despite explicitly defining 'US/Central' inside the initial timestamp conversion, 5 hours were subsequently subtracted the initial time provided.
What additional steps/alterations can I make to ensure that the initial time provided is unchanged, defined as US/Central, and that I can subsequently change to UTC?
Python's fromtimestamp assumes that your input is UNIX time, which should refer to 1970-01-01 UTC, not some arbitrary time zone. If you encounter such a thing nevertheless (another epoch time zone), you'll need to set UTC and then replace the tzinfo:
from datetime import datetime
from dateutil import tz # pip install python-dateutil
ts = 1636039288.815212
dt = datetime.fromtimestamp(ts, tz=tz.UTC).replace(tzinfo=tz.gettz("US/Central"))
print(dt)
# 2021-11-04 16:21:28.815212-05:00
# or in UTC:
print(dt.astimezone(tz.UTC))
# 2021-11-04 20:21:28.815212+00:00
Note that I'm using dateutil here so that the replace operation is safe. Don't do that with pytz (you must use localize there). Once you upgrade to Python 3.9 or higher, use zoneinfo instead, so you only need the standard library.
I have the following code which am using to monitor Azure ADF pipeline runs. The code uses 'RunFilterParameters' to apply a date range filter in extracting run results:
filter_params = RunFilterParameters(last_updated_after=datetime.now() - timedelta(1), last_updated_before=datetime.now() + timedelta(1))
query_response = adf_client.activity_runs.query_by_pipeline_run(resource_group, adf_name, row.latest_runid,filter_params)
The above works ok, however it is throwing a warning:
Datetime with no tzinfo will be considered UTC
Not sure how to add timezone to this or just suppress the warning?
Please help.
"no tzinfo" means that naive datetime is used, i.e. datetime with no defined time zone. Since Python assumes local time by default for naive datetime, this can cause unexpected behavior.
In the code example given in the question, you can create an aware datetime object (with tz specified to be UTC) like
from datetime import datetime, timezone
# and use
datetime.now(timezone.utc)
If you need to use another time zone than UTC, have a look at zoneinfo (Python 3.9+ standard library).
I want to show expiry dates for SSL certificates to the user. These expiry dates are in UTC, so when the expiry date is today at noon, it will show 12/08/2020 12:00:00. However, since I am in the Berlin timezone, that means the certificate will actually expire at 14:00:00 localtime, which is what I want to show to the user. I tried the following:
end_date = certificate_end_date.replace(tzinfo=timezone.utc).astimezone(tz=None)
But since the certificate is valid until 2045, this produces the following error message:
OverflowError: timestamp out of range for platform time_t
I searched and people suggested just using a timedelta, but that is complicated again due to daylight savings time. There has to be a proper way to do this? I am using Python3.7.
I solved it by calculating the timedelta as recommended elsewhere, although it still looks kind of ugly to me:
from datetime import datetime, timezone
now = datetime.now()
offset = now.replace(tzinfo=timezone.utc) - now.astimezone(timezone.utc)
localtime = utc_time + offset
If, under Python 3.7:
from datetime import datetime
datetime(2019, 4, 1).timestamp()
I'm getting 1554073200.0. Shouldn't it be 1554076800.0 instead (i.e. 1 more hour) according to https://www.unixtimeconverter.io/list/2019/april?
I'm getting this error only after 1st April 2019. For instance, if I try:
datetime(2019, 3, 31).timestamp()
I get 1553990400.0, which I believe it's the expected result.
I'm using Spyder 3.3.6. Thank you for your help
The problem is that your datetime is "naïve". It doesn't know what timezone it's in. The timestamp method (as specified in the docs) is assuming you want the local timezone, which in your case has a DST change on the 31st March 2019. To get the answer you want, you need to set the timezone. For example,
from datetime import datetime, timezone
d = datetime(2019,4,1, tzinfo=timezone.utc)
d.timestamp()
which gives 1554076800.0 as you expected.
So I'm trying to convert a bunch of hours (10:00:00, 14:00:00, etc) from a given timezone to UTC.
When I do so, I keep maddeningly getting things back like "15:51:00".
When you get to that line, and print what value it's using, it's using something like:
1900-01-01 12:00:00-05:51
Which is fine, except for the -05:51 bit. I have no idea why that -05:51 is there, and it's causing me problems. UTC conversion is hour to hour, yes? I think it's got something to do with my timezone conversions, but I really don't get why they would be doing that.
Here's a minimal example that has the same erroneous output; it returns 15:51:00 when it should just return a flat hour, no minutes.
import datetime
from dateutil import tz
jj = datetime.datetime.strptime("10:00:00", "%H:%M:%S")
tzz = tz.gettz('US/Central')
def constructstring(tzz,x):
inter2 = x.replace(tzinfo=tzz) #ERROR HAPPENS HERE (I'm pretty sure anyways)
inter3 = inter2.astimezone(tz.tzutc())
return inter3
print(constructstring(tzz,jj).strftime("%H:%M:%S"))
You are not specifying a date when you create the jj datetime object, so the default date of 1900-01-01 is used. Timezones are not fixed entities; they change over time, and the US/Central timezone used a different offset back in 1900.
At the very least, use a recent date, like today for example:
# use today's date, with the time from jj, and a given timezone.
datetime.datetime.combine(datetime.date.today(), jj.time(), tzinfo=tzz)
If all you need is a time, then don't create datetime objects to store those; the datetime module has a dedicated time() object. I'd also not use strftime() to create objects from literals. Just use the constructor to pass in integers:
jj = datetime.time(10, 0, 0) # or just .time(10)
Other good rules of thumb: If you have to deal with dates with timezones, try to move those to datetime objects in UTC the moment your code receives or loads them. If you only have a time of day, but still need timezone support, attach them to today's date, so you get the right timezone. Only convert to strings again as late as possible.