Skip to content

plot: Doesn't handle datetime at DST beginc correcly #738

Closed

Description

@MKleusberg

Details for the issue

Just found this on the Debian bug tracker

I have a sqlitefile with timestamps and some data values.  When I plot the
data vs datetime with the builtin plot function, I get a weird outlier when
the datetime is 2006-03-26 02:00

A minimal example is here:
http://www.nmdb.eu/~steigies/debian/NEWK_2006_1h.sqlite

This also happens when I change the minute to other values as long as the
hour stays at two.  I did not specify a timezone in the datetime, so if I understand
http://sqlite.org/lang_datefunc.html
correctly, this is taken as UTC.

March 26 was the beginning of Daylight Saving Time in
most of Europe, the hour between 2 and 3 does not exist on this day:

http://www.timeanddate.com/time/dst/2006.html

slitebrowser changes the datetime for this hour to ~ the year 2100 when
plotting the data.  When I change my timezone from Europe/Berlin to
America/New_York, this glitch in the plot happens on April 2nd, the day DST
began in the USA.

I think sqlitebrowser should plot the data as given in the file, without
shifting values during DST switch to the year 2100 if I give it data in UTC. 
If I specified a timezone, I do not expect the data to appear in 2100
either, mabye that data should be dropped from plotting, with a warning
given to the user instead.

thanks,
Christian

I'm still able to reproduce this with the latest version. It's also highly unlikely that this is a Linux-only bug.

Useful extra information

I'm opening this issue because:

  • DB4S is crashing
  • DB4S has a bug
  • DB4S needs a feature
  • DB4S has another problem

Activity

  1. added
    bugConfirmed bugs or reports that are very likely to be bugs.
    on Aug 21, 2016
  2. justinclift commented on Aug 21, 2016

    @justinclift
    Member

    It seems like DB4S isn't handling invalid data points (eg datestamp that doesn't exist) in a good way.

    Would the better approach be to ignore the invalid points + show a warning, or something else?

  3. justinclift commented on Aug 21, 2016

    @justinclift
    Member

    Well spotted btw. 😄

  4. justinclift commented on Aug 21, 2016

    @justinclift
    Member

    Useful conversation snippet from Christian (the original reporter), copied from email.

    Dropping invalid dates would be ok (at least it does not let me worry about
    problems in my sqlite files). Specifying the timezone on the commandline or
    inside sqlitebrowser (if it does not use UTC as in the sqlitefile) would be
    even nicer as I could view all my data in sqlitebrowser.

    When we put time into fixing this, we should probably ask Christian (via the email in the Debian bug report) to test the fix.

  5. added a commit that references this issue on Mar 5, 2017
  6. MKleusberg commented on May 5, 2017

    @MKleusberg
    MemberAuthor

    Can somebody test if this is fixed by Oleg's change? Seems to work fine now for me at least.

  7. justinclift commented on May 5, 2017

    @justinclift
    Member

    Christian, the original reporter, tested our latest source today and confirms it's now working:

    I checked out the source from github and tested it with the minimal example
    as well as a full data file. Looks good, no more jups in the x-axis.

    Looks good!

    Thanks heaps for getting this taken care of @prutz1311, and @MKleusberg for the reminder. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugConfirmed bugs or reports that are very likely to be bugs.

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions