RFC2: Date/Time proposal

[J. Alex Aycinena]

Charles,

What impact would your proprosal have on reports?

Alex

> Message: 13
> Date: Sat, 19 Jul 2008 05:52:05 -0700
> From: "Charles Day" <cedayiv at gmail.com>
> Subject: Re: RFC2: Date/Time proposal
> To: nbinont at yahoo.ca
> Cc: GnuCash Devel <gnucash-devel at gnucash.org>
> Message-ID:
>        <1d6843d80807190552q63c36e1bqf51266dfafd36ca4 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Jul 18, 2008 at 11:28 PM, Nathan Buchanan <nbinont at gmail.com> wrote:
>
>>
>>
>> On 7/19/08, Charles Day <cedayiv at gmail.com> wrote:
>>>
>>> I'm going to go ahead and throw out another proposal for comments. I'm
>>> calling this RFC2. Unless specifically stated, all that follows refers to
>>> transaction posting dates and times only.
>>>
>>> Since to my knowledge the feature of having a "time zone per account" has
>>> not actually been requested by any user, I'm going to leave that
>>> completely
>>> out of this proposal. However, if there ever was a need for that feature
>>> in
>>> the future, this proposal is readily extensible to support that.
>>
>>
>>
>> First off, I agree that for most (maybe all?) cases the timezone per
>> account is not needed. That being said, I was a bit nervous removing the
>> option of adding timezones in the future, so I think this proposal better
>> addresses the needs without restricting things in the future.
>>
>> Here's what I was thinking. The general idea is to allow "date only"
>>> functionality, but also allow optional entry of a time of day:
>>> 1. Let there be a checkbox preference named "Show transaction posting
>>> times". Off by default.
>>> 2. When this preference is off, registers look the same as today; a time
>>> of
>>> day is not seen and cannot be entered.
>>> 3. When this preference is on, users can enter a posting time of day on
>>> any
>>> transaction, but do not have to.
>>> 4. For each transaction, if a time of day has not been entered then the
>>> GnuCash data file will only save the date. Otherwise, both date and the
>>> time
>>> of day will be saved.
>>
>>
>> This is likely to become messy in the datafile: some dates without times
>> and some with times. When we read this data in, we would have to keep track
>> of which dates have times and which do not. I'd think it would be much
>> simpler to create a default time and always write out the time (assuming, of
>> course, that the user had not specified a time). And since the timezone is
>> always known, there will never be any ambiguity or shifting dates.
>>
>
> I believe several users have expressed that they do not want a time written
> to their data file if they never actually entered one. That's one of the
> things I am proposing to support with this proposal. Saving defaulted
> transaction times would mean that when you read the file back in, you
> wouldn't know which times were user-entered and which times were defaulted.
>
>
>> 5. The user does not specify any time zone, and none is saved.
>>
>>
>> ok, though I'd advocate that the timezone be specified (and possibly saved)
>> as UTC. If we do not do this, the user may decide to change the timezone on
>> their machine while gnucash is open and possibly save different data than
>> was read in.
>>
>
> Under this proposal, the time zone on the machine is completely ignored. The
> time zone is a constant set internally by GnuCash. So changing the machine's
> time zone is not an issue.
>
>
>> 6. In case the user has some transactions with times and some without, and
>>> needs to sort transactions by posting time, let there be a preference
>>> exists
>>> to determine how to treat the transactions that do not have posting times.
>>> (Possible options might include treating them as if they had been entered
>>> at
>>> the beginning of the day, or at the end of the day, or at any specific
>>> time
>>> in between.)
>>
>>
>> I'd allow a default transaction time instead, as above.
>>
>> Sound good? Well, here's the part you may not like. All of the above can be
>>> implemented by GnuCash internally by use of a timestamp and a flag
>>> indicating whether the time of day was entered by the user. Let me
>>> explain:
>>> A. All timestamps would use the same time zone, which never varies. Users
>>> do
>>> not pick the time zone. It is hard coded and is never seen in the GUI and
>>> never saved to the data file.
>>
>>
>> Unless the user changes timezones with the file open...
>>
>
> GnuCash would ignore the system time zone.
>
>
>>
>> Nathan
>>
>> B. If a transaction is read from a data file and it contains both a date
>>> and
>>> a time, these are combined with the time zone from (A) to compute a
>>> timestamp. The flag is raised to indicate that the time of day was entered
>>> by the user.
>>> C. If a transaction is read from a data file and it contains only a date,
>>> a
>>> time of day is added on according to the preference indicated in (6)
>>> above,
>>> and these are combined with the time zone from (A) to compute a timestamp.
>>> The flag is lowered to indicate that the time of day was NOT entered by
>>> the
>>> user.
>>> D. To display the date in the GUI, GnuCash takes the time zone from (A)
>>> and
>>> the timestamp, and uses them to compute the date.
>>
>> E. To (optionally) display the time in the GUI, GnuCash takes the time zone
>>> from (A) and the timestamp, and uses them to compute the time of day.
>>> F. When saving a transaction to the data file, if the flag is raised to
>>> indicate that the time of day was entered by the user, then GnuCash writes
>>> the date and time of day to the data file.
>>> G. When saving a transaction to the data file, if the flag is lowered to
>>> indicate that the time of day was NOT entered by the user, then GnuCash
>>> writes only the date to the data file.
>>>
>>> My reasons for suggesting the continued use of timestamps internally are
>>> that it makes it very easy to sort transactions by posting time, and that
>>> the necessary code changes to get this done is still fairly small. So
>>> there
>>> is probably some reasonable chance of it actually getting done, which is
>>> an
>>> important factor to consider. Several of you who want to use "date only"
>>> internally have made fair points about simplicity, but I have made the
>>> point
>>> that the effort of getting from here to there would be much larger. So you
>>> would have to ponder the question of who would devote the necessary time
>>> for
>>> that larger effort.
>>>
>>> OK, now praise this, ask questions, or rip it apart (more likely) as you
>>> see
>>> fit. Thanks to everyone so far for remaining fairly civil while discussing
>>> this potentially incendiary topic.
>>>
>>> Cheers,
>>> Charles
>>>
>>
> -Charles
>