"Charles Day" <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
