Re: [Gnuplot-info] Problem with date format

[Thomas S. <t.s...@fz...>]

Hans-Bernhard Bröker-2 wrote:
> Thomas Sefzick wrote:
>> ...it's not so easy to repair...
>
> Nor was it easy to get working to the extent it does.  Calendars are a 
> major pain in the lower back.

i agree, it took me some hours just to get a rough idea of what the code
is doing.

>> BUT 'time_tic_just' is called for each tic, adjusting the tic to a
>> grid based on 'timelevel[axis]' 
>
> ... and just in case somebody wonders about that: yes, it is necessary. 
> That's what you get for pretending that a month were an equidistant 
> tick interval that can be sequenced, miniticked, and so on.  Well, it's 
> not, and so all major ticks have to be adjusted to actually fit on the 
> scale.
>
> I think the proper patch would involve a routine that works much like 
> quantize_time_tics(), but leaves alone the input 'tics'.

like it's done now - the only disadvantage is that 'quantize_time_tics()'
does too much, it sets 'timelevel[axis]' in a way that max. 12 or 20
tics are allowed, without changing the user-specified tics intervall (the
change is done inside 'quantize_time_tics()' and returned, but not used in
calling routine).

some simpler algorithm would be sufficient:

------------------------------------- snip
---------------------------------------------
--- axis.c.orig	2007-12-19 21:11:08.000000000 +0100
+++ axis.c	2008-03-03 20:51:18.000000000 +0100
@@ -795,8 +795,15 @@
      * effect, it defines timelevel[axis]. */
     /* HBB 20011204: moved this up --- round_outward() needs
      * timelevel[axis], too */
-    if (this->is_timedata && ticdef->type == TIC_SERIES)
-	quantize_time_tics(axis, tic, fabs(this->max - this->min), 20);
+    if (this->is_timedata && ticdef->type == TIC_SERIES) {
+	if      (tic >= 365*24*60*60.) timelevel[axis] = TIMELEVEL_YEARS;
+	else if (tic >=  28*24*60*60.) timelevel[axis] = TIMELEVEL_MONTHS;
+	else if (tic >=   7*24*60*60.) timelevel[axis] = TIMELEVEL_WEEKS;
+	else if (tic >=     24*60*60.) timelevel[axis] = TIMELEVEL_DAYS;
+	else if (tic >=        60*60.) timelevel[axis] = TIMELEVEL_HOURS;
+	else if (tic >=           60.) timelevel[axis] = TIMELEVEL_MINUTES;
+	else                           timelevel[axis] = TIMELEVEL_SECONDS;
+    }
 
     if (autoextend_min)
 	this->min = round_outward(axis, ! (this->min < this->max), this->min);
------------------------------------- snip
---------------------------------------------

this patch doesn't seem to break compatibility, at least the only official
example i could find (in 'help set xtics') works.

the patch doesn't cover strange cases like '60 days tic intervals', but
these intervals do not fit into our calendar anyway.

would it be a good idea to extend the list of gnuplot-defined variables
by YEAR_SEC, MON_SEC, WEEK_SEC, DAY_SEC ?
it would make specifying the tics interval in 'set xtics' easier.

-- 
View this message in context: http://www.nabble.com/Re%3A--Gnuplot-info--Problem-with-date-format-tp15817386p15825322.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.