Time issues

[joa-quim]

This issue, against the rules, reports more than one bug but they are kind of cousins.

A more distant cousin.
This one works

gmt basemap -R1920T/2028T/6800/7400 -JX12c/0.5c -Ba -f0T --TIME_EPOCH=0000-01-01T -png lixo

but this would fill your disk with a multi-GB PS file. The problem is, as -Vd would show, that the guessed annotations are 30 sec apart.

gmt basemap -R1920T/2028T/6800/7400 -JX12c/0.5c -Ba -f0T --TIME_EPOCH=0000-01-01T --TIME_UNIT=y -png lixo

So, adding the relevant information --TIME_UNIT=y makes that 1920T is no longer recognized as time??? Or the time unit is lost?

Now, this is what? A excess rounding?

echo 1921.0417 | gmtconvert -f0T --TIME_EPOCH=0000-01-01T --TIME_UNIT=y
1921-02-10T00:00:00

When, with GMT.jl, I save a file of that type of data, I get

1921-01-16T01:45:16	6986
1921-02-15T11:56:51	6946
1921-03-17T22:08:25	6879

but that is also wrong, as both Matlab and Julia confirm, the right date should be

1921-01-16T05:17:31.2	6986
1921-02-15T15:00:00.0	6946
1921-03-18T00:42:28.7	6879
...

[joa-quim]

Now, this is what? A excess rounding?

No, it's pure time-travel

echo 21.0417 | gmtconvert -f0T --TIME_EPOCH=0000-01-01T --TIME_UNIT=y
0417-01-21T00:00:00

echo 21.04 | gmtconvert -f0T --TIME_EPOCH=0000-01-01T --TIME_UNIT=y
0021-01-04T00:00:00

echo 21.0 | gmtconvert -f0T --TIME_EPOCH=0000-01-01T --TIME_UNIT=y
gmtconvert [WARNING]: No data records provided

[joa-quim]

The problem is that 21.01 is interpreted as yyyy.jjj where jjj is the day-of-year and that is why 21.0 says "No data records provided".

So, apparently there is no way of passing dates in decimal years.

@WalterHFSmith, @remkos. Do you remember anything about this?

[WalterHFSmith]

There should be a way to do that. Or did we expect that decimal years could be treated like any non-time coordinate?

…

On Apr 25, 2025, at 7:04 AM, Joaquim ***@***.***> wrote: joa-quim left a comment (GenericMappingTools/gmt#8718) <#8718 (comment)> The problem is that 21.01 is interpreted as yyyy.jjj where jjj is the day-of-year and that is why 21.0 says "No data records provided". So, apparently there is no way of passing dates in decimal years. @WalterHFSmith <https://github.com/WalterHFSmith>, @remkos <https://github.com/remkos>. Do you remember anything about this? — Reply to this email directly, view it on GitHub <#8718 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APUT6GNJJOSPVNY63JGYDZL23IJD5AVCNFSM6AAAAAB3SESFGGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMZQGEYDINZUGI>. You are receiving this because you were mentioned.

[joa-quim]

Yes, ofc it must exist. Just forgot that in my first post I have one such example. But it was one done with Julia that calls gmtwrite, which is a module that we cannot call from command line. At to help it further a VisualStudio update just f... the capacity to debug the the julia call so now I'm blind to try debug the path that leads to the decimal year processing ... and try to fix the bug that results in an error of ~5 hours.

[joa-quim]

After a full day of debugging I was able to achieve a little victory. -Ba guessing now (in #8721) works too in the case.

gmt basemap -R1920T/2028T/6800/7400 -JX12c/0.5c -Ba -f0T --TIME_EPOCH=0000-01-01T --TIME_UNIT=y -png lixo

Still have no idea on how to pass in a decimal time to gmtconvert. And I strongly suspect that error in converting decimal years to date time (in my first post) is related with comment in the code of gmt_init_time_system_structure()

		case 'y':	case 'Y':
			/* This is a kludge: we assume all years are the same length, thinking that a user
			with decimal years doesn't care about precise time.  To do this right would
			take an entirely different scheme, not a simple unit conversion. */
			time_system->scale = GMT_YR2SEC_F;
			break;

We should document this somewhere.