datetime: encapsulates datetime operations and add milliseconds

[phweyland]

Once done we can tweak datetime accuracy as needed.
First step to fix #10398

[TurboGit]

A first review. TIA.

[phweyland]

I could continue the next steps on the same PR, but as datetime usage is a bit spread over the code I would prefer to avoid too many rebases.

[phweyland]

Probably remain some bugs to be found out, but the main feature is there.

• The $(EXIF_MSEC) variable is available at import and export time.
  • more changes on import side as time_t doesn't hold milliseconds
• Milliseconds are read/written from/to database, Exif data, xmp data and xmp file.
  • to get them on images, 'resfresh exif'
• Can be modified in geotagging module
  
• The bd doesn't change as sqlite ignores the text field sizing.
• EDIT, if xmp, at import time, exif data are overwritten by xmp data and msec are not present.

I need some advice:

• do we need to expose milliseconds in image information ? (Not done so far)
• should they been hidden in collect module ? (BTW collections with one item do not make a lot of sense...)
  
• would we want to remove existing tm and time_t (unix time) occurrences ? (Remain a lot!)

I haven't changed watermark because it can access the standard variable (it should only use standard variables). If I touch to it, that will be to unify variables.

I still need to check the impact on collect, collection and timeline which access directly the bd datetime values.

Any comment or question is welcome.

[johnny-bit]

• do we need to expose milliseconds in image information ? (Not done so far)

IMO yes

• should they been hidden in collect module ?

IMO Yes. I agree that "single item collections" are not useful

• would we want to remove existing tm and time_t (unix time) occurrences ? (Remain a lot!)

Ideally yes. Given that 2038 is "soon" and GNU Libc needs explicit param to enable 64bit time support, moving to glib time handling seems like a good idea overall. But maybe not in the scope of this PR. A lot of such occurences means a lot of rebases to do if pr is long-lived which may cause problems in the long run... So maybe separate PR after this gets merged and in several PRs to get changes in quickly and without need for lots of rebases :)

[TurboGit]

• do we need to expose milliseconds in image information ? (Not done so far)

Maybe only on a tooltip?

[phweyland]

I've added a preference to show or not the milliseconds in "image information", but I'm wondering if it won't be better as global preference to control "geotagging" as well.
Not everybody needs them and that takes space.

EDIT: now controls image information and geotagging

[phweyland]

Details...

• Sqlite is able to manage iso-8601. So far dt follows exif standard, including in bd. This may simplify some queries involving datetime. I have not looked too much to timeline.c code but that may provide some advantage. @AlicVB, what do you think ?
• g_date_time_format_iso8601() is available since glib 2.62 but dt requires 2.56 (exclusively).
• The standard (iso-8601) separator between seconds and microseconds seems to be the dot (".") whatever the locale. However on the UI we could use the locale decimal character. Would anyone know how to get it based on the machine locale ?

[johnny-bit]

• g_date_time_format_iso8601() is available since glib 2.62 but dt requires 2.56 (exclusively).

the requirement for 2.56 comes from the fact that minimum supported ubuntu for 3.8 release was set to be 18.04 LTS. since that'll be over 4 y old by the time of 4.0 release I'd recommend switching minimum glib to 20.04 LTS which has glib 2.64

That way we'd also be able to drop need to support older compillers :)

[quovadit]

it's awesome to have milliseconds as import-variable, thanks a lot!

Is there a chance to use $(EXIF_MSEC) only if $(EXIF_HOUR)$(EXIF_MINUTE)$(EXIF_SECOND) would not be unique?

[phweyland]

Is there a chance to use $(EXIF_MSEC) only if $(EXIF_HOUR)$(EXIF_MINUTE)$(EXIF_SECOND) would not be unique?

Not sure to understand the question.
The main usage I can think about is to rename images taken in burst mode, then several ones by seconds.
But I don't see how to use it without the upper units, except if you know what you are doing (for example you know that all images are taken in the same second).
Other point, my Nikon has not a millisecond accuracy but gives only the 1/100 sec.

[quovadit]

I would like to have unique filenames using date+time.
In most cases, it is enough to use yyyy-mm-dd_hh-mm-ss in order to be unique.
But sometimes there are multiple images in one second, so I need millisesonds.

In order to have short and readable filenames (in most cases) it would be great if millilseconds are only added to the filename if otherwise it would not be unique.

So using a variable $(EXIF_MSEC_IF_NOT_UNIQUE) would look like this:
2022-01-28_22-15-35.cr2
2022-01-28_22-15-37.cr2
2022-01-28_22-15-37-150.cr2
2022-01-28_22-15-37-892.cr2
2022-01-28_22-15-42.cr2

[phweyland]

Got it !
Expand variables does its job properly but has no understanding of the variables meaning...
This said, it could have a retry mode in case of homonymy, and associated strategy for it, like either using an index or using optional variables as you suggest. But that's another story I'm afraid ...

[TurboGit]

Maybe a better wording?

Apart from that it is all good to me.

[TurboGit]

Sorry Philippe but you have also some conflicts here!

[TurboGit]

@phweyland : The conflict was easy to resolved, I've done so and merged this. Thanks again!