Hi all, if you're going down the path of adding support for time zone information, there is one thing that is not clear to me: If you are planning to rely on "QDateTime" (i.e. Qt) for this purpose, you're getting time zones based on UTC, but you're lacking support for UT1, i.e. leap seconds and related issues. I know this is another huge can of worms, but bear with me: For satellite imagery it actually matters. A lot more imagery is taken from very low orbits nowadays, so a time difference of a single second can - theoretically - account for up to roughly 7 km. On the one hand side, most providers calibrate the imagery and provide it with proper UTC time stamps. On the other hand side, the way UTC is "smoothed" over UT1, i.e. how UT1 is correctly converted to UTC and vice-versa, is not perfectly standardized. From practical experience, too many people handle it in too many slightly different ways. So when dealing with longer time series, going back to the original UT1 time stamps (if available) is always the better and much more accurate option. Having said that, if you want a future-proof solution, you should definitely go beyond what Qt offers. I'd suggest to look for a battle-tested library in this field with some astronomical background. I guess you're going to try to solve this in C++, which makes sense, but just as a reference, I'd suggest to have a look at astropy's implementation of `Time`. It has saved me from serious trouble a lot recently and serves as some sort of reference implementation for many projects.
https://docs.astropy.org/en/stable/time/index.html By the way, ArcGIS does not support this level of accuracy yet, too, if you need another selling point. And since a lot of you are running on PostgreSQL or supporting PostgreSQL-based setups, a little excerpt from its manual: "Technically, PostgreSQL does not use UTC because leap seconds are not handled." In older versions it ironically stated "Technically, PostgreSQL uses UT1 because leap seconds are not handled." It's a common theme across a lot of GIS software, which is more and more becoming a thing. Best regards, Sebastian _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
