© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
I would like to point out a possibility that may not have been considered in order to resolve this problem. I am not familiar with the code but I have some understanding of timezone issues so my input may be useful (or possibly not).
In the xml file the date posted for a transaction is stored as a local time with a UTC timezone offset. My timezone is UTC+0100 and if I enter a transaction for 20 July then the value in the xml file is '2009-07-20 00:00:00 +0100'. This is the start of 20th July (local time) with the fact that the local time is 1 hour ahead of UTC. In order to extract the date from this for display in the register it is merely necessary to interpret the date portion and ignore the rest. At the moment, I think, it is converted to the current local timezone first (which is what can cause the date change). It may therefore be that the problem can be fixed in this case merely by changing the interpretation of the data from the xml file. There is no need to change the format of the data in the file itself.
When the data is stored to a database however the situation changes. The date/time is stored in UTC with no indication of the timezone. Data is therefore lost (compared to the xml file) and I can see no way to recover it. I would therefore suggest that it may be highly desirable that this is sorted before the first full release of the version that supports the database is made available.
A possibility to avoid this is to store the posted date/time in local time rather than UTC. In the xml file this is just a matter of losing the +0100. In the database, normally entered transactions would have a time of 000000 (preceeded by the date) and special ones for book closing and so on can have 235959 or whatever is appropriate. As this would always be interpreted as a local time (whatever the user's current timezone) the date would always be exactly what is stored in the xml file or db.
Apologies if the above is a load of rubbish due to my lack of knowledge of the inner workings, but I thought I should provide my thoughts just in case they are helpful in finding a solution for this problem which seems to be rather problematic.