-B with a time axis adds a full year from a tinny fraction of a year

[joa-quim]

Note that annotations start at beginning of 2025 when xmin = 2025.96

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

and this one even errors

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

basemap [ERROR]: Offending option -R2026.00136986T/2026.99863014T/17.2463856192/20.0914327114

[joa-quim]

This the Claude's analysis

● Issue #8865: Root Cause Analysis

  The Bug

  gmt_scanf_argtime() in gmt_io.c (line 2682) cannot handle fractional/decimal year inputs like 2025.96T or 2026.00136986T.

  What Happens

  When the input is 2026.00136986T:

  1. Line 2730: strchr(s, 'T') finds the trailing T, so the function treats it as an absolute time string rather than a relative float.
  2. Line 2736: Nothing follows the T, so clock is set to x = 0.0 (midnight).
  3. Line 2772: The loop searches for a - delimiter between year and month, but 2026.00136986T has no dashes — only a decimal point. The
  loop stops at T.
  4. Line 2784: sscanf("2026.00136986", "%4d-%2d-%2d", ...) reads only the integer part ival[0] = 2026 and stops at the . since it's not
  a -. Returns j = 1.
  5. Line 2786: Since only one field was read, the loop sets ival[1] = 1 (month = January) and ival[2] = 1 (day = 1).
  6. Result: The input 2026.00136986T is silently interpreted as 2026-01-01T00:00:00, completely discarding the fractional part
  .00136986.

  This is why the first test case (-R2025.96T/2027.04T/...) starts annotations at the beginning of 2025 instead of near December 2025,
  and why the second test case (-R2026.00136986T/2026.99863014T/...) fails entirely.

  The Fix

  The function should detect that the input is a decimal year (contains . before T and has no - delimiters) and treat it as relative time
   via gmt_scanf_float() (as it already does on line 2732 when there is no T), then convert from decimal years to absolute time using the
   TIME_EPOCH and TIME_UNIT settings.

  Connection to Issue #8930

  This is the same class of bug as #8930 (14-day annotation intervals producing spurious labels). Both stem from the time axis code
  mishandling edge cases: #8930 in gmtlib_moment_interval() truncating to month boundaries instead of stepping by the requested interval,
   and #8865 in gmt_scanf_argtime() silently dropping the fractional part of decimal year inputs.