Fix incorrect time annotations near year boundaries

[Esteban82]

Done with Claude Sonnet 5

Test with:

gmt basemap -JX15c/10c -B -f0T --TIME_EPOCH=0000-01-01T --TIME_UNIT=y -R2025.96T/2027.04T/17.2/20.2 -png lixo1

And gmt basemap -JX15c/10c -B -f0T --TIME_EPOCH=0000-01-01T --TIME_UNIT=y -R2026.00136986T/2026.99863014T/17.2463856192/20.0914327114 -png lixo2

Closes #8865

[joa-quim]

The case is more complex than this. See #8937 I will need to come to this and decisions must be taken (#8937 discuss it if I still remember). And, I want a Opus or Fable analysis on this. Not Sonnet only.

[Esteban82]

I’ve had a look at it. I’m not sure it’s the same problem. I get the impression it isn’t.

[Esteban82]

I still think this is a different issue. This PR fixes the case where a fractional date is used in the region specification.

Test with:

I tested it with the command below, using 2026.997 and 2027.01 as the region limits.

gmt basemap -JX15c/10c -B -f0T --TIME_EPOCH=0000-01-01T --TIME_UNIT=y -R2026.997T/2027.01T/17/20 -png lixo3

Without this fix

GMT truncates the fractional part of the dates and ends up using a region covering the entire year 2026.

With this fix

The resulting range is just over 5 days, which is the expected behavior.

[joa-quim]

OK, let's get in in and see where it fits in this list of time annotations troubles.