https://bugs.documentfoundation.org/show_bug.cgi?id=117732
--- Comment #12 from Noel Grandin <noelgran...@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._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
