TIME_UNIT affects custom annotations then the absolute time is used
|Target version:||Candidate for next minor release|
Create custom annotations file:
echo "1995-01-01T a 1995
2000-01-01T a 2000
2005-01-01T a 2005
2010-01-01T a 2010
2015-01-01T a 2015">int
Create frame without specifying TIME_UNIT:
$GMT psbasemap -JX10cT/10c -R1993-01-01T/2016-06-01T/143.3/146 -BSEnw -By1 -Bxcint -P >test1.ps
All annotations are fine.
Now add TIME_UNIT:
$GMT psbasemap -JX10cT/10c -R1993-01-01T/2016-06-01T/143.3/146 -BSEnw -By1 -Bxcint -P --TIME_UNIT=d >test2.ps
There is now annotations on x-axis. But projection specifies what I use absolute times and the manual says what TIME_UNIT is the units of relative time data since epoch, so it has not sense for absolute time projections.
- Status changed from New to Feedback
Perhaps the documentation needs to be updated to explain a few things. With custom annotations there is actually data i/o going on, i.e., reading in those annotation times. These are assumed to be in absolute time formats, normally. However, if you rather prefer to give relative time in the units of your choice (say days) from some epoch then you are free to specify annotations that way, provided you set the TIME_UNIT/EPOCH accordingly. So setting TIME_UNIT but then not giving relative time is a problem. We still have an outstanding bug in this situation that we are looking at (we added a test that currently fails to remind us). Thus, we recommend you stick with absolute calendar time specifications and lay off the TIME_UNIT setting.
- Status changed from Feedback to Resolved
- Target version set to Candidate for next minor release
- % Done changed from 0 to 100
The TIME_UNIT setting ended up changing the type of axis annotation from a to i (interval) since the time unit in effect (d) is a time interval. But we don't want that to change for custom annotations as al the a,i,f,g etc stuff is in that file. So I deactivated that particular test when custom annotations are in effect. Your example now works for me. r16816.