RFC2: Date/Time proposal

[Charles Day]

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

> "Charles Day" <cedayiv at gmail.com> writes:
>
> >> 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.
>
> 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?

If we don't know which times are user-entered and which are defaulted, then
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.


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