RFC: Timestamps/timezones proposal

[Stuart D. Gathman]

Mike or Penny Novack wrote:
>
>> The key is that the register would display date,time, AND TIMEZONE.  
>> The timezone lets the user recognize that .......
>>  
>>
>
> I am going to ask again.
>
> On July 18th at 14:30 EST the bookkeeper enters a transaction 
> involving accounts whose "time zones" are all also EST (in other words 
> there will be NO time zone issue here) with a transaction date of July 
> 15th.
>
> I'll repeat to make that very clear. The date of the transaction is 
> July 15th. As is NORMAL the transaction is not entered in the books 
> "real time" but entered at some later point in time when the 
> bookkeeper gets around to it.
>
> OK -- the question is -- what TIME is associated with that transaction 
> in GnuCash? Why? In other words, since the bookkeeper never entered 
> any "effecitve time" for the transaction (just a date) then where does 
> that time come from? What is its meaning? That's why I would consider 
> the time assigned to be "random" or "meaningless" (say the system 
> assigned a constant time of day value --- zero bits of information). 
> Yes of course, I would consider the time of day at which the 
> bookkeeper happened to get around to it (if that is what gets used) a 
> "random" time. Remember, just because the bookkeeper posts transaction 
> A (effective July 15th) before posting transaction B (effective July 
> 15th) doesn't mean "transaction A took place before transaction B.
Currently, gnucash sets the time of day to 00:00 for the local time 
zone.  Derek proposed using the constant 12:00Z (12 noon UTC) instead.  
This has the property that the date displayed by asctime is the same for 
all time zones with absolute offset < 12.  Unfortunately, there are a 
number of border cases along the international date line (including 
Tongo and DT) where this doesn't work.  There was never a serious 
proposal for the program to supply the time of day entered (although the 
timestamp for when entered is stored in *addition* to the transaction date).

There *is* a serious proposal from Charles Day to let the user 
explicitly enter the time of day for transactions.  Instead of saving 
the timezone, Charles proposed that the times would display with 
whatever timezone is current on the system.  I said that this is 
unacceptable, and that a timezone needs to be saved with the entered 
time of day.  I was thinking of the current system timezone, but others 
have proposed a user settable timezone for each register that is used 
for transactions entered on the register instead of the system 
timezone.   I still maintain that the timezone, wherever it comes from, 
must be saved with the transaction so that the entered dates (and time 
of day) don't change.

In case the user doesn't want to enter time of day (99.9% of use), 
gnucash should use a fixed timezone.  The natural choice for a fixed 
timezone is UTC, as Derek proposes.  So for date only operation, gnucash 
would use UTC for transactions, ignoring system timezone, and set time 
of day to 12:00Z.   There needs to be more debate on the UI issues 
before any kind of time of day entry for transactions is usable.