[Libreoffice-bugs] [Bug 117732] Firebird: Migration: Time values are being changed during migration process ( data type TIME and DATETIME)

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=117732

--- Comment #12 from Noel Grandin <noelgrandin at gmail.com> ---

If you look at the hsqldb code we use, inin

  workdir/UnpackedTarball/hsqldb/

I see a comment in src/org/hsqldb/HsqlDateTime.java

   HSQLDB uses the client and server's default timezone for all DATETIME
   operations. It stores the DATETIME values in .log and .script files using
   the default locale of the server. The same values are stored as binary
   UTC timestamps in .data files. If the database is trasported from one
   timezone to another, then the DATETIME values in cached tables will be
   handled as UTC but those in other tables will be treated as local. So
   a timestamp representing 12 noon stored in Tokyo timezone will be treated
   as 9 pm in London when stored in a cached table but the same value stored
   in a memory table will be treated as 12 noon.

and then if I look for the code which loads Time values, I find in

  src/org/hsqldb/rowio/RowInputBinary.java

that the code looks like

    protected Time readTime() throws IOException, HsqlException {
        return new Time(HsqlDateTime.getNormalisedTime(readLong()));
    }

where Time is java.sql.Time, which has a constructor like:

    /**
     * Constructs a <code>Time</code> object using a milliseconds time value.
     *
     * @param time milliseconds since January 1, 1970, 00:00:00 GMT;
     *             a negative number is milliseconds before
     *               January 1, 1970, 00:00:00 GMT
     */
    public Time(long time)

and getNormalisedTime looks like

    public static long getNormalisedTime(long t) {
        synchronized (tempCalDefault) {
            setTimeInMillis(tempCalDefault, t);
            resetToTime(tempCalDefault);
            return getTimeInMillis(tempCalDefault);
        }
    }

which, if I inline all the methods it calls, looks like:

    private static Calendar tempCalDefault = new GregorianCalendar();
    public static long getNormalisedTime(long t) {
        synchronized (tempCalDefault) {
            tempCalDefault.setTimeInMillis(t);
                 tempCalDefault.set(Calendar.YEAR, 1970);
                 tempCalDefault.set(Calendar.MONTH, 0);
                 tempCalDefault.set(Calendar.DATE, 1);
                 tempCalDefault.set(Calendar.MILLISECOND, 0)
            return tempCalDefault.getTimeInMillis();
        }
    }

So the answer is that the time value is UTC milliseconds, which needs to be
normalised to a 0-24 hours range.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20180525/58f618df/attachment.html>