I use LO Base and forms to manage my record/CD collection. I use MySQL as my database. Up until version 6.0.7.3 (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.
