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
Related
I have a TDMS file with a bunch of DateTime values with relevant instrumentation data.
The issue I am having is:
TDMS file >>>> Python Reads
4/20/2021 12:00:01 AM >>>> 2021-04-20 04:00:00.597573
4/20/2021 8:00:01 PM >>>> 2021-04-21 00:00:00.570708
This is messing up transfers to the database because it is not accurate.
This is my code:
dfscaled = tdmsfile.__getitem__("Data (Scaled)").as_dataframe()
for index, row in dfscaled.iterrows():
print(row["Timestamp"])
I am using the NPTDMS library. Any ideas on how to fix this?
So I ended up contacting the author and he was helpful enough to send a response:
TDMS files internally store times in UTC. You don't say how you're
getting the values in the "TDMS file" column but I assume this is from
a program that converts times into your local timezone to display
them. There is an example of how to convert UTC times from a TDMS file
into your local timezone in the documentation.
If you are storing these times in a database though, I would strongly
recommend you store times in UTC rather than your local timezone as
local times can be ambiguous due to daylight savings changes, and UTC
is easily understood from anywhere in the world without having to know
the local timezone where the data originated.
If you still feel like making the change from UTC to EST then this should do it:
fmt = "%Y-%m-%d %H:%M:%S.%f"
x=pd.to_datetime(row["Timestamp"]).tz_localize('UTC').tz_convert('US/Eastern').strftime(fmt)
dtm=pd.to_datetime(x[:-3])
print(dtm)
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).
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.
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]
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.