[gillins]

What does this PR do?

It fixes a seg fault when writing datetime Raster Attribute Table columns using the Python bindings when no timezone was supplied. Previously, the code expected the timezone to be None if not present. However Python uses a different C struct to represent the datetime if no datetime is present. Instead the code needs to check the hastzinfo field before attempting to access the timezone, otherwise it could be accessing beyond the end of the struct.

I looked at using Python's C macros to help, but there seemed to nothing specific for the datetime type.

What are related issues/pull requests?

AI tool usage

Not used.

Tasklist

• Make sure code is correctly formatted (cf pre-commit configuration)
• Add test case(s)
• Add documentation
• Updated Python API documentation (swig/include/python/docs/)
• Review
• Adjust for comments
• All CI builds and checks have passed

[gillins]

OK I have learnt a few important things since originally submitting this:

1. So it is really important to check hastzinfo. If this is not set, a different (smaller) struct is used and you end up reading off the end when retrieving the timezone info.
2. There is no macro to access the timezone info from a datetime (although ones for date and time - and no, these don't do the right thing).
3. The macro for checking hastzinfo isn't available on Python 3.8 (which Ubuntu 20.04 uses) so we must access this var directly.
4. The test suite only checked the timezone present case. My use case was with no timezone, hence I was getting a crash. I have now updated the test suite to check both cases.

[jratike80]

How important it is to use PyDateTime_TIME_GET_TZINFO, if it is not necessarily available, and if in that case something else must be used? Can't you use just a single path but still prevent segfault?
Sorry if I my questions do not make sense, I am not a programmer myself.

[gillins]

thanks @jratike80 just updated the title to make it a bit clearer. Important thing is to check the hastzinfo before accessing timezone information - you can't rely on the timezone being None. The macros didn't help in the end - they either didn't do the right thing for datetime, or weren't available in Python 3.8.

[jratike80]

You still mention using the macro in the description. Does the change affect only raster attribute tables, or more generally datetime handling in GDAL?

[gillins]

Ah right, description updated - thanks. No, this is very specific to Raster Attribute Tables.