time_t - When does it break?

Graham Leggett minfrin at sharp.fm
Fri Jul 18 06:20:04 EDT 2008

Ian Lewis wrote:

> In other words, the
> timezone in which it was entered needs to be stored to figure out what
> day it was entered? Otherwise, wouldn't the local timezone be enough
> to serve as metadata when converting to a date?

The local timezone changes over time, and this is the source of the 
problem. I moved from one country to another and suddenly my VAT returns 
went haywire because transactions on the 1st of the month were now 
suddenly on the last day of the previous month, and therefore in a 
different VAT period.

Others might live in NY and fly to LA on business for a few days, 
updating their timezone while there. They will face the same problem.

Base accounting cares about dates and not times because accounting wants 
to break accounts into periods. If the date is ambiguous, then the 
period into which that transaction falls is ambiguous, and this affects 
things like tax and VAT returns, which in turn leaves the end user 
facing tax penalties.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3287 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080718/29eef26a/attachment.bin 

More information about the gnucash-devel mailing list