After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 574681 - Axes for dates and times
Axes for dates and times
Status: RESOLVED FIXED
Product: libgoffice
Classification: Other
Component: Graphing / Charting
unspecified
Other All
: Normal normal
: ---
Assigned To: Emmanuel Pacaud
Jody Goldberg
Depends on:
Blocks: 338624
 
 
Reported: 2009-03-09 20:33 UTC by Morten Welinder
Modified: 2009-05-21 15:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
goffice patch (15.01 KB, patch)
2009-05-20 15:49 UTC, Morten Welinder
none Details | Review
gnumeric patch (15.01 KB, patch)
2009-05-20 15:49 UTC, Morten Welinder
none Details | Review

Description Morten Welinder 2009-03-09 20:33:20 UTC
(Just thinking aloud here)

We need to improve axis support for dates and times.

* Manual entry of upper/lower limits and tick sizes need to understand
  things like 00:30:00.  Note, that interpretation depends on the format
  in some cases such as "00:30" which is either 30 minutes or 30 seconds.

* We need to pick lower/upper limits sanely.  Ditto for ticks.

  This probably is not hard for time axes -- it is basically just a matter
  of different number bases being used.

  For dates, things are worse.  Limits are probably not too hard, but ticks
  will not be uniform.  If lower limit is 1-Jan-2009 and upper limit is
  31-Dec-2009, then the obvious major tick is "1 month".  If we stay in
  days-since-1900 space, then ticks are non uniform since month lengths
  differs.  We do not absolutely have to stay in that space, though.
  We could internally map to years-since-1900 and allocate 1/12 of a year
  to each month and each day the suitable fraction of the month they are
  in.

  Having such uniform months may be desirable when the axis spans more than
  2 months, but it might look weird for an axis from 29-Jan to 3-Feb.
Comment 1 Morten Welinder 2009-03-12 13:36:40 UTC
Any thoughts?
Comment 2 Morten Welinder 2009-03-26 02:59:07 UTC
We now pick sane bounds and ticks for times.
Comment 3 Morten Welinder 2009-03-27 22:07:56 UTC
We now also pick sane bounds and ticks for dates.  Currently it is strictly
linear in terms of days, so January and February will have different widths.
Let's see how that works before we go wild.

That leaves parsing and unparsing.
Comment 4 Morten Welinder 2009-05-20 15:49:06 UTC
Created attachment 135035 [details] [review]
goffice patch
Comment 5 Morten Welinder 2009-05-20 15:49:28 UTC
Created attachment 135036 [details] [review]
gnumeric patch
Comment 6 Morten Welinder 2009-05-20 15:51:20 UTC
This seems to take care of parsing and unparsing.
Comment 7 Morten Welinder 2009-05-21 15:30:38 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.