Interval of weekly consolidation(7 days) starts always with a timestamp on Thursday

[taotao100]

Hello,
I'm using RRD4j rel. 3.0 and 2.2.1 to persist my time series data thru following configurations in five archives by a step of 300 seconds.

  rrdDefPowerConsumption.addArchive(AVERAGE, 0.999, 1, 3 * 24 * 12);
  // resolution=hourly (granularity 5 min) 3 * 24 hours
  rrdDefPowerConsumption.addArchive(TOTAL, 0.999, 12, 3 * 24);
  // resolution=daily (granularity 5 min) 3 * 30 days
  rrdDefPowerConsumption.addArchive(TOTAL, 0.999, 12 * 24, 3 * 30);
  // resolution=weekly (granularity 5 min) 2 * 52 weeks
  rrdDefPowerConsumption.addArchive(TOTAL, 0.999, 12 * 24 * 7, 2 * 52);
  // resolution=monthly (granularity 5 min) 5 years = 5*12 months
  rrdDefPowerConsumption.addArchive(TOTAL, 0.999, 12 * 24 * 30, 5 * 12);

I observed following phenomenon in my populated weekly data set, that start date of each weekly interval is always Thursday, no matter in which time span I populated my test data? Is it a feature?
Is it possible to adjust boundary of consolidated data to Monday so that I can get the aggregated data set based on calendar weeks.

regards
Xi

[fbacchella]

Pay attention that internal calculation in rrd4j is done using UTC. The timezone is only used for rendering of graph legend.

[wvdemeer]

I can explain why it starts on Thursday:

• The unix epoch is Thursday, January 1, 1970
• rrd4j stores dates in seconds from epoch
• rrd4j uses modulo to normalize time intervals, see for example:

  rrd4j/src/main/java/org/rrd4j/core/Util.java

  Lines 114 to 116 in 62c4776

  	public static long normalize(long timestamp, long step) {
  	return timestamp - timestamp % step;
  	}

  
  which is used here:
  

  rrd4j/src/main/java/org/rrd4j/core/Archive.java

  Lines 259 to 263 in 62c4776

  	public long getEndTime() throws IOException {
  	long arcStep = getArcStep();
  	long lastUpdateTime = parentDb.getHeader().getLastUpdateTime();
  	return Util.normalize(lastUpdateTime, arcStep);
  	}

(To fix this, rrd4j would have to store an "offset" as well. I don't think this is a trivial change.)