LO Base has changed how it ses time fields

I use LO Base and forms to manage my record/CD collection. I use MySQL as my database. Up until version (the gap between releases may be more than one), I could enter my track times as HH:MM:SS and LO would store them correctly. I also wrote a stored procedure to calculate the accumulated times at each track so that at the end I had the total tracks time for a record side or CD. The stored procedure worked correctly as well.

Today, I bought a new CD (actually it came today), and I went about my procedure of entering the data. When I entered the track times in the above mentioned format, everything looked fine. I entered a terminal and ran my stored procedure to calculate the accumulated times. The procedure ran fine (I thought) and I ran a query external to LO Base. To my surprise, the times were shifted within the format. For example, a track that had a time of 00:02:57 now showed as 02:57:00. I went back to the form in LO Base to see what was going on. I looked first at the CD just entered, and the times were correct. However, when I looked at some CD/Records previously entered, they were all wrong. Rather than show the times in HH:MM:SS format as they had been entered, they only showed the minute value; the seconds were gone, and the format seemed to be that of an integer rather than time. By that I mean there was no 00:02, there was just 2. That was true of all the previous records/CDs entered.

I ran a query external to LO Base on some of the earlier database entries, and they were all correct as to time. I went back to LO Base and checked the properties for the time fields in the form and found something interesting. The format was 13:45:00. That explained why my time was shifted (I think) in the new CD record. It also meant that I could not choose the format I wanted because I checked and the only other time that did not have PM in it was 13:45.

So it seems that LO Base does not honor HH:MM:SS at all because it shifts it to HH:MM in MySQL. My guess is someone decided to treat the Time data type as a Timestamp data type.

One other clue is that when I was accumulating my total times with the stored procedure, the leftmost part of the Time fields was well past 24; in fact it was in the 60s. So because LO Base does not seem to have a true Time data type anymore, it shifts the minutes to the hours position and the seconds to the minutes position.

I have no idea what is going on with all the other entries that were created in a previous version/release of LO Base. All I know for now is they have made a big mistake.


Do not see the problem you are having. Using LO v6.4.4.2 from TDF on Ubuntu 20.04 Mate with MySQL v8.0.20 using JDBC connection and connector ‘mysql-connector-java-8.0.12.jar’

Here is data in Base:

image description

And in MySQL Workbench:

image description


As you noted, insure the selected format is correct:

image description

If your screens are different it may be a version issue.

Edit 2020-05-28:

Just tested on Ubuntu 18.04 with:



Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8
CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: gtk3;
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

MySQL v5.7.30

Results same as posted above. No problems.

Here are some screen shots showing what I described. First, I show the new one I entered today.

Then the MySQL Query

It ism obvious that Base moved the minutes to the hours and the secons to the minutes.

Now one that was entered in a previous release/version of LO Base

And finally the same data from a MySQL query

I believe I entered the others with version 5 of LO, but I may have entered one or 2 when I went to version 6. I am on Ubuntu 18.04 and MySQL 5.7. The pictures speak for themselves. Un fortunately, you need a magnification glass to see the details.