boto3: ssm describe_instance_patches OverflowError: date value out of range
I am currently looking into boto3 ssm client and calling the describe_instance_patches for a given instance, and i run into the following error: “*** OverflowError: date value out of range”
I have used the boto3 library version: boto3==1.9.42 (This is the same as the default in Lambda. I have also used the latest version: boto3==1.9.203 and this has the same issue. i prefer the 1.9.203 release as this includes pagination for the resposne)
I was able to resolve this on my own machine by changing my environment variable for TZ to UTC:
export TZ="/usr/share/zoneinfo/utc"
I believe this issue happens because Amazon works on UTC, so the timezone on the response is UTC and is being converted to my local timezone, which errors.
Any assistance on this would be ace.
If you want test this yourself (I am assuming you have already got credentials present for boto3):
import boto3
from pprint import pprint
def get_instance_patches(client, instance_id):
paginator = client.get_paginator("describe_instance_patches")
for page in paginator.paginate(InstanceId=instance_id):
for patch in page.get("Patches", []):
yield patch
def list_instances(client):
paginator = client.get_paginator("describe_instance_information")
for page in paginator.paginate():
for instance in page["InstanceInformationList"]:
yield instance
if __name__ == "__main__":
client = boto3.client("ssm")
for instance in list_instances(client):
instance_id = instance["InstanceId"]
for patch in get_instance_patches(client, instance_id):
pprint(patch)
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 24 (10 by maintainers)
Hi, I don’t believe it is fixed, I’m currently using latest versions of botocore and boto3 and facing the exact same issue. @jack1902 could you confirm if you’re still seeing the issue on your side as well ?
@jack1902 - This issue occurs only when the service returns negative timestamp. I don’t have any exact time frame but there is already a corresponding CR for it. I will post here when i will get any update from the service side.
Can you please post the logs for CLI ? I am curious to know what is the response you are getting from the service. You can enable the log by adding
--debugto your code.@jack1902 - Sorry for the late reply. I am not able to reproduce this issue on a mac with latest version of boto3 with time zone same as yours(GB). As mentioned by @visitjonathan , are you also getting the error on windows machine ? I have not tried to reproduce this issue on windows ec2 instance. Today i will run the code in a windows ec2 instance and see if i can reproduce the issue.
If you are getting the error on a mac then it would be really helpful if you can provide me the full debug log. You can enable log by adding
boto3.set_stream_logger('')to your code.I’m facing this issue too. The AWS CLI command works fine, but the boto equivalent fails with timestamp parsing errors. stacktrace.txt
I’m working on a Windows AWS EC2 instance, but unfortunately changing the timezone to UTC doesn’t fix the problem for me.
My default timezone is AEST:
$> tzutil /g AUS Eastern Standard Timebut when I change it to UTC I get exactly the same result. I’m using the following command to change the timezone, which takes effect immediately on the system:
$> tzutil /s UTCIf I try and reboot the system, the AD policies simply change it back to AEST.
Running the boto function through a lambda function works, so I’d hazard a guess it’s still something to do with my machine’s time settings. Regardless, the boto function should be able to handle different time zones.
On my same windows machine I can use the AWS CLI without any issues:
$> aws ssm describe-instance-patches --instance-id <instance_id> { "Patches": [ { "Title": "2018-05 Update for Windows Server 2016 for x64-based Systems (KB4132216)", "KBId": "KB4132216", "Classification": "CriticalUpdates", "Severity": "Important", "State": "Installed", "InstalledTime": 1528812000.0 }, { "Title": "2018-11 Update for Windows 10 Version 1607 for x64-based Systems (KB4465659)", "KBId": "KB4465659", "Classification": "SecurityUpdates", "Severity": "Critical", "State": "Installed", "InstalledTime": 1542546000.0 }, and so on...so there definitely are some patches there for the function to find…