Time axis, manual ticks every 14 days, labeled as "%b %d", labels aligned with the tick?

Q&A
1

Hi, I want to set time axis ticks every 14 days, and format tick labels as “%b %d”, aligned with the axis ticks. Data range is a bit less than 2 months

This thing is done in gnuplot using the following code

set term pngcairo enhanced size 800,80 font "Helvetica,14"
set output "gnuplot.png"
set xdata time
set timefmt "%Y-%m-%d"
set xrange ["2019-02-15" to "2019-04-08"]
set yrange [0 to 1]
unset ytics
set xtics 3600*24*14 nomirror out
set format x "%b %d"
set border 1
plot 0/0 notitle

gnuplot

in gmt when i specify -Bxa14Rf7R the following --FORMAT_DATE_MAP="o dd" is not respected, label format is just date of month, positioned a bit off the ticks:

gmt basemap -R2019-02-15T/2019-04-08T/-20/+20 -JX10c -BS -Bxa14Rf7R -png R --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev

R

When I specify -Bxa2Uf1U --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev label format is correct but the labels are aligned far away from the ticks:

gmt basemap -R2019-02-15T/2019-04-08T/-20/+20 -JX10c -BS -Bxa2Uf1U -png U --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev

U

When I specify -Bxa14Df7D --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev I get extra label at Apr 01 right on top of Mar 29:

gmt basemap -R2019-02-15T/2019-04-08T/-20/+20 -JX10c -BS -Bxa14Df7D -png D --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev

D

With -Bxa14Df7D --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev i get essentially the same labels as before, aligned slightly off, month disregarded:

gmt basemap -R2019-02-15T/2019-04-08T/-20/+20 -JX10c -BS -Bxa14df7d -png d --FORMAT_DATE_MAP="o dd" --FORMAT_TIME_PRIMARY_MAP=abbrev

d

Now I am out of options and hope somebody can point me in the right direction!

2

Hi,
That reminds me of : GitHub · Where software is built

3

Here is what Claude has to say about the label overlapping bug.

● Bug Analysis

  With -Bxa14D and range 2019-02-15T to 2019-04-08T, here's the step-by-step execution through gmtlib_moment_interval() in
  gmt_calclock.c:665-695:

  1. Init (Feb 15): day_m=15, (15-1) % 14 = 0, no floor. First annotation: Feb 15
  2. Step: day_m + step = 15 + 14 = 29 > 28 (Feb has 28 days) → truncates to Mar 1
  3. Step: 1 + 14 = 15 ≤ 31 → Mar 15
  4. Step: 15 + 14 = 29 ≤ 31 → Mar 29
  5. Step: 29 + 14 = 43 > 31 → truncates to Apr 1 (BUG!)
  6. Step: 1 + 14 = 15 ≤ 30 → Apr 15 (beyond max, loop ends)

  The expected sequence should be: Feb 15 → Mar 1 → Mar 15 → Mar 29 → Apr 12.

  Root Cause

  Lines 680-688 of gmt_calclock.c: when day_m + step exceeds the month length, the code truncates to the 1st of the next month instead of
   simply advancing step days:

  if (p->cc[0].day_m + p->step > kml) {
      /* Truncate to 1st of next month  */
      p->rd[1] = gmt_rd_from_gymd (..., next_month, 1);  // resets to day 1
  }
  else
      p->rd[1] = p->rd[0] + p->step;  // this branch is correct

  Fix

  The simplest fix would be to always advance by step days:

  p->rd[1] = p->rd[0] + p->step;

  This would produce Mar 29 + 14 = Apr 12 (correct) instead of truncating to Apr 1.

  However, the truncation to day 1 may be intentional for small steps (e.g., a7D) where aligning to month boundaries makes sense. A safer
   fix would be to only truncate when step is small enough that month-boundary alignment is meaningful (e.g., step < ~15), or perhaps
  only when step evenly divides typical month lengths.
4

If I do what Claude suggest in first place we get this

lixo

but it is also right that present code was done on purpose so I don’t want to just blindly change it. This needs further discussion/opinions on what to do and should that should be carried over a Github issue.

5

Curious where does this Feb 15 come from? For example, Gnuplot apparently (naively) counts 2-week intervals starting from the epoch. It lands with 2019-02-21 etc that is a whole number of 2-week periods from the epoch of 1970-01-01.

(implying also no matter what time range was specified by the user all the time ticks and labels remain at exactly the same positions)

6

Look, I don’t know the answer to many of this question, but for this I see that -R starts at

so I find it natural (and correct) that first label is Feb 15

7

  1. Time axis/ticks/labels seems buggy since long ago. This makes me thinking not many at all use it, so getting opinions may be hard simply cause there aren’t (m)any. But I hope I’m wrong here.

  2. do you mean I need to create a bug report on github about this specific issue? I can. Or you meant some other type of discussion topic that you and the other developers start there on your own?

8

For example I am fine with gnuplot’s (naive) approach. But I know time is a complex subject with subtle issues like leap seconds etc. Gnuplot just skipped all that to make their lives easier I guess.

9

Yes. That’s where things get better documented after all.

10
11

The Problem with Time & Timezones - Computerphile

12

Warning for the others: don’t waste your time. I tried to scroll through the video, got ~6 ads thrown at me, lasting longer than the video I managed to see before the ads popped up.