Appeared after upgrading 8.2.0 -> 8.3.0 appimage, but didn't verify by reverting back.

Please upload a sample image that can reproduce the problem.

But it could also be a bug from the beginning of digiKam-8.3.0 development, which has now been fixed.
Test whether reloading the metadata from the images resolves the issue.

Maik

It's actually image file creation date which gets +2 h time (shown at "File Properties", while "digiKam properties" shows correct time). At least iNat plugin seems to send this wrong time to iNaturalist as it strips all metadata from pictures itself.

The date displayed in the file properties on the Properties tab is the file's modification date, not its creation date.
Everything is correct with this modification date, I compared it here with Windows Explorer and it can of course differ from the creation date.
If the iNaturalist plugin uses the modification date, this will of course be fixed.

Maik

Ok, I may have misinterpreted origin of the bug in the end here. My original notice was that there seems to be "Z" timezone sent to iNaturalist now after upgrade. And this may be the cause for +2 h time which constantly gets submitted. This problem started to occur after upgrade to 8.3.0 and there wasn't any issues before. 

Just confirmed that 8.2.0 sent same image resulting time "08:49 EET" shown at iNaturalist while 8.3.0 resulted to "10:49 EET". When trying to edit them via web interface after submitting, editing shows "08:49:16" and "08:49:16Z" respectively.

Git commit 77b6ffb8fdf6d07f02c4c3f335c155cb5c468120 by Maik Qualmann.
Committed on 26/03/2024 at 21:47.
Pushed by mqualmann into branch 'master'.

set time spec to local time in the iNaturalist plugin
Additional fix list view item color.
FIXED-IN: 8.4.0

M  +1    -1    NEWS
M  +6    -6    core/dplugins/generic/webservices/inaturalist/inatwindow.cpp

https://invent.kde.org/graphics/digikam/-/commit/77b6ffb8fdf6d07f02c4c3f335c155cb5c468120

Git commit 8ebfb4435ef3d9c71dfc12d630c70b0b17030717 by Maik Qualmann.
Committed on 26/03/2024 at 21:56.
Pushed by mqualmann into branch 'master'.

set time spec to local time in the INatTalker

M  +1    -0    core/dplugins/generic/webservices/inaturalist/inattalker.cpp

https://invent.kde.org/graphics/digikam/-/commit/8ebfb4435ef3d9c71dfc12d630c70b0b17030717

It seems that 8.4.0 fixes other time issues too, like correct time based file renaming for video files which has long been several hours wrong.

However the original problem is still partially there. Now it seems that no timezone information is not submitted at all. I have my camera not set to use daylight saving time, so now as timezone information is not present, it is expected that such standard time is submitted which is not the case.

Most video files do not have time zone information. The information in the QuickTime container, which is used by many manufacturers, has a UTC time for the creation date with no time zone information. Because according to the standard this field is an integer and not a string. A string can represent a time zone. See also a recent post in the ExifTool forum.

Maik

Sorry I was talking about two separate things. I just wanted to mention that video files are now renamed with correct time like photos. I possibly shouldn't have mixed it here. This is separate thing.

The problem that still occurs is about *photos* where this timezone data is saved (I currently don't have similar need for videos). Timezone information is not transferred eg. via iNat plugin but just plain datetime without timezone. I have adopted using cameras without daylight saving time because I experienced problems with file renaming on some digikam versions years ago which caused different issues, and kept the habit still. As the timezone is not transferred I have one hour wrong data transferred.

Because of time zone support we have Bug 251357.
Time zone offset metadata is only available in relatively newer camera devices, more or less.

Maik