RFC2: Date/Time proposal

[Charles Day]

On Sat, Jul 19, 2008 at 7:16 PM, Nathan Buchanan <nbinont at gmail.com> wrote:

>
>
> On 7/19/08, Charles Day <cedayiv at gmail.com> wrote:
>>
>> 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.
>>
>
> If we want to track whether the user entered the time or not, I think it
> would be much cleaner if we had a separate flag in the datafile for that.
> Inferring it from the date format seems a bit unintuitive to me.
>

I've done some work in industries that use YYYYMMDD with an optional HHMM
tacked on the end, or even HHMMSS.SSSSSS, as an industry-wide format for
passing data within and between companies. So I guess, having done that, I
don't find it unintuitive. One of the ideas of this proposal is to avoid
saving posting times that the user didn't enter, since a few users have
spoken out against this. Another option to consider is to write the date and
time out as separate fields in the data file.

-Charles


> Just my 2 cents.
>
> Nathan
>
>  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.
>>
>
> ok
>
>  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
>>
>
>
>
> --
> <><><><><><><><><><><><><><><>
> "Even if you are on the right track, you'll get run over if you just sit
> there" - Will Rogers
>