[rrd-developers] thinking about localtime and graphing

[Alex van den Bogaerdt]

> DEF:weekly=test.rrd:ifHCInOctets:AVERAGE:step=3600:ctrigger=%V:tz=CET
> 
> (%V would be the ISO week number,  but you could use any expression you want).
> 
> Whenever the value of the ctrigger changes, one 'grouping' comes to
> an end. If the original data is not available at 'step' resolution
> from rrd fetch, some interpolation might arificially enhance the
> resolution prior the blocking it again.

I'm sure you have already thought about daylight saving. Some questions which pop up in my brain are:

I am not aware of such a time zone, but nevertheless you will need to have a 100% sure answer to the following question:
Is there any time zone in the world which applies DST, and where the switch to/from DST is happening at midnight?
If there is such a time zone, to which day does the extra hour (or whatever the offset is) belong to?
Does strftime do it right? In every implementation?

Other questions, which may not be specific to the current case, but it may become more important now, and/or result in more cases where RRDtool does not do what the user expects it to do:

Is 00:00-12:00 (or midnight to noon, or whatever range) invalid during summer time, when the user specifies time zone CET ? Or does CET also cover the last sunday in March, 1am GMT, until the last sunday in October, 1am GMT?
If it does, is 2011-08-01 03:00 CET equal to 2011-08-01 02:00 UTC or to 2011-08-01 01:00 UTC ?

How to handle at-style time specifications, asking for example for 02:00-03:00 on october 30, 2011, european time? Will it be just one hour (because you ask CET, not both CET and CEST), or will it be two hours?

Does strftime behave consistently?

I don't have the answers, but I will look forward to the discussion about this topic.
HTH
Alex