Even Rouault

I've tried this PR on Linux and "make install" fails with: ``` CMake Error at cmake_install.cmake:80 (file): file INSTALL cannot find "/home/even/openjpeg/openjpeg/build/OpenJPEGTargets.cmake": No such file or directory. ```

> The expected [axis orientation](https://proj.org/en/9.3/usage/projections.html#axis-orientation) for the PROJ string should be `+axis=wnu` Actually it should +axis=nwu, shouldn't it ? and for a similar reason, for EPSG:4326, it should be +axis=neu....

> But ultimately, compatibility with previous forms to not introduce bugs should take precedent. not sure to understand what you mean by that. But basically my view of PROJ4 string...

Closing as not planned

> Only for GPKG, the datetime is written fine (naive datetime is kept without changes to the time), but when read the datetime is assumed to be UTC... Format limitation....

> Not sure I fully understand, but so a workaround for FlatGeobuf is to just use/assume UTC? In Arrow, you must indicate the timezone of a datetime column, for the...

> How about using the first row as heuristic? Such complication would have to be implemented in all drivers that support datetime with potentially non-UTC timezone... At least all those...

> that one would be non controversial Actually I was almost forgetting that OGRLayer::GetArrowStream() has a TIMEZONE option (cf https://gdal.org/en/latest/doxygen/classOGRLayer.html#a3ffa8511632cbb7cff06a908e6668f55). That you can specify to be UTC (the GeoPackage driver...

> to instead of discovering the (lack of) timezone up-front per table/layer to rather do it when actually reading the data and then using the first row being read (or...

> where we essentially use `OGR_F_GetFieldAsString` to retrieve the data of a datetime field inside a `OGR_L_GetNextFeature` loop) General remark: be careful: The GetFieldAsXXXX() methods are essentially cast from the...