gmtconvert is not able to return time converted input from wrappers

[joa-quim]

using GMT

result = sample1d([0 0; 4 1], inc=0.5);
gmtconvert(result, f="i0t/o0T", par=(TIME_EPOCH="1969-07-21T02:56:00", TIME_UNIT=:d))

Returns the same as input (telling it to save to file, works). The reason seems convoluted as the workflow follows quite different paths for return as memory address (the wrappers output) or when saving to file.

[joa-quim]

By Claude's

● That confirms it — gmtconvert.c does no time conversion on the data values. The conversion from relative to absolute time (or vice versa) only happens
  at the I/O formatting layer: when data is read as text, gmt_scanf converts the input string to internal time (seconds since epoch). When data is written
   to a file, gmt_ascii_format_col formats the internal value according to the output column type (-fo0T). But the numeric values in
  D[GMT_OUT]->table[tbl]->segment[seg]->data[col][row] are never modified.

  When a wrapper (Julia/Python) calls gmtconvert, the output is returned as a numeric matrix via the API memory mechanism — the formatting step is
  bypassed entirely, so the raw internal values are returned unchanged.

  Issue #8836: Root Cause

  This is an architectural limitation, not a bug in gmtconvert specifically.

  How it works for file output

  When writing to a file, the chain is:
  1. Input: -fi0t → gmt_scanf reads column 0 as relative time, converts to internal seconds-since-epoch
  2. Data processing: values stay as internal time (seconds since epoch)
  3. Output: -fo0T → gmt_ascii_format_col formats column 0 as absolute time string (e.g., 1969-07-23T02:56:00)

  The conversion from relative to absolute time only happens during text formatting at step 3.

  How it fails for wrapper/memory output

  When returning data to a Julia/Python wrapper:
  1. Input: same as above — values converted to internal time
  2. Data processing: values stay as internal time
  3. Output: GMT_Write_Data with memory destination → the raw double array is returned directly to the wrapper. No text formatting occurs, so the -fo0T
  setting is never applied. The wrapper gets the same numeric values that were in the input.

  Why the data appears unchanged

  In this specific case, the input is [0 0; 4 1] with TIME_EPOCH=1969-07-21T02:56:00 and TIME_UNIT=d. The -fi0t reads column 0 as relative time (days
  since epoch), which internally becomes seconds since epoch. But when returned to Julia as raw doubles, these internal seconds are meaningless without
  the formatting step. If the wrapper doesn't apply the reverse transformation, the user just sees the original (or scaled) numbers.

  The fix

  This would require one of:
  1. Convert the data values in-place before returning to the wrapper — when output column type differs from input column type, apply the conversion to
  the actual data array, not just at the formatting level
  2. Return column type metadata along with the data so the wrapper can perform the formatting itself
  3. Force text output when -fo time conversion is requested and output is to memory

  This is fundamentally a design issue in how GMT's I/O layer handles type conversions — they're treated as display formatting rather than data
  transformations, which breaks down when the "display" step is skipped.