RFC: Timestamps/timezones proposal

Charles Day cedayiv at gmail.com
Fri Jul 18 22:04:03 EDT 2008


On Fri, Jul 18, 2008 at 3:24 PM, Mike or Penny Novack <
stepbystepfarm at mtdata.com> 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.
>

Assuming you want "date only" behavior and would not be using "time of day"
entry features, I don't think the time and time zone recorded by GnuCash
matter provided it is the same for every transaction. So pick something -
say 00:00 UTC. You would never see that time or time zone in the GUI, and
the OS time zone would be ignored. In other words, you would never know the
time or timezone unless you looked at the code or the data file. From the
GUI, it looks like a date and acts like a date.

You could provide "date only" users with a choice of default time and time
zone, rather then hard coding them, but every time they changed the settings
you'd have to convert all the existing data.


> Michael
>
> --
> There is no possibility of social justice on a dead planet except the
> equality of the grave.
>
>
-Charles


More information about the gnucash-devel mailing list