RFC2: Date/Time proposal

[Derek Atkins]

"Charles Day" <cedayiv at gmail.com> writes:

>     First, we're assuming that we ARE going to implement that feature,
>     which we don't necessarily need to.
>
> If we're not going to ever allow user-entered times on transactions, then we
> don't need this proposal. Just make the time zone a constant. This could be
> the immediate step to take; introduction of a time entry feature could come
> later.

I think the timezone should be a constant either way, and the
"default time" in the timestamp should also be a constant.
Then we can choose down the road whether to implement time-of-day
entry ala bug #89439

>     Second, I think it's perfectly fine to choose a default time regarless.
>
> Does the user get a choice of default time? If not, we don't need the
> preference from (6).

I would say "no".  I dont think it's needed.

>     Third, if we're just using the "time" to allow sorting of transactions
>     within a day, I don't think we need to store a timezone either.  We
>     just use GMT and let the user choose a time other than the default
>     (which I still think should just be 1200).
>
> We wouldn't need to store the time zone, but it would do no harm (keeps the
> file format the same).

True.

> 0000 or 2359 seem like better options to me for a default time, i.e. treat
> transactions without user-entered times as being "beginning of day" or "end of
> day". Of course, if we have preference (6) then the user can make that call.

I still think 1200 is "better" because if we DO ever implement ToD entry
it makes it easier to move transactions forward/backwards from the default
without having to change the ToD on EVERY transaction that day.

>     As for the users who "dont want a time in their datafile", I'm perfectly
>     happy to ignore that "request".  They are absolutely correct that the
>     UI (register, reports, etc) MUST NOT behave differently when the user
>     changes a timezone, but I see no reason to support a requirement that
>     the data file NOT contain a time.
>
> Storing the time in the data file forces preference (6) into being a permanent
> choice, unless we also store a flag.

I'm afraid I don't follow your logic here.  Could you explain why
you say this?  We already store a time now and we don't have a
preference (6).  Had GnuCash kept a stable timezone always then
nobody would have every noticed there was a problem (except bug #89439)
and this discussion would be a VERY different animal.

>     Having said all that, we COULD put a flag in the KVP of the transaction
>     to flag that the time was entered by the user.
>
>  That would make preference (6) more flexible. I assume that's preferable.

Flexible is good..  However keep in mind that while KVP is nice
for XML, it's NOT nice for SQL.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available