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.
Regards,
Graham
--
-------------- 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