RFC2: Date/Time proposal

[Charles Day]

On Tue, Jul 22, 2008 at 1:26 AM, Derek Atkins <warlord at mit.edu> wrote:

> "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.
>

What I mean is that if users were able to do time entry, and we stored the
time but not a "user-entered" flag, then we wouldn't be able to tell which
times were user-entered. So when you changed preference (6) it could only
apply to new transactions.

However, if we are only talking about fixing the immediate bug, then there's
no problem. This issue wouldn't need to be addressed until time entry
features were added.


> >     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
>

-Charles