RFC2: Date/Time proposal

[Charles Day]

On Mon, Jul 21, 2008 at 11:11 AM, Derek Atkins <warlord at mit.edu> wrote:

> Quoting Charles Day <cedayiv at gmail.com>:
>
>  > 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.
>>>
>>> Here's where I need to disagree.  I'd like to see as little change
>>> to the data file format as possible!
>>>
>>> Right now we're storing an ISO Date-Time string.  We should continue
>>> to do so, even in the cases where the user did NOT input an actual
>>> "time".
>>>
>>> I really think that data file compatibility is also important.
>>>
>>> Personally I'm willing to forego any time zone support at all and just
>>> always use/display GMT dates.  But we can still store a timestamp and
>>> ignore the time portion.
>>>
>>>
>> How would we know which times were user-entered and which times were
>> defaulted? That's the only issue I have with keeping the file format
>> unchanged. If we must store a posting timestamp in the data file, does
>> Nathan's idea of saving a flag with each transaction appeal to you?
>>
>
> Does it really matter?
>
> 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.

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

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

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.

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.

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.

the user's preference for (6) now becomes a permanent choice, and that
>> situation seems an awfully lot like forcing "date only" users to pick
>> default transaction times. If they wanted to change the preference later,
>> it
>> could only affect future entries; we wouldn't be able to go through the
>> existing transactions and adjust their default times, because we wouldn't
>> know which transactions had been defaulted.
>>
> If we don't know which times are user-entered and which are defaulted, then
>
> I'm happy to forego #6 completely.   I'm also happy to have it only
> affect "new" transactions, which means changing it has no effect
> on existing transactions...  Which is just fine...  Which would
> mean that we STILL dont need to store that information.
>
> Note, however, that the Book Closing code does make an assumption about
> the timestamps of both closing transactions and real transactions
> to determine when the books have already been closed (so it doesn't
> re-close them).
>
>  -Charles
>>
>
> -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