Transaction Posted Time

[Aaron Laws]

On Sun, Jun 19, 2016 at 6:15 PM, John Ralls <jralls at ceridwen.us> wrote:

>
> > On Jun 19, 2016, at 1:07 PM, Christian Stimming <christian at cstimming.de>
> wrote:
> >
> > Again, I would suggest to switch the posted-date data type to a date-only
> > (without time) as soon as possible, as discussed in bug 137017 and
> various
> > discussions throughout the years.
>
> Christian,
>
> You and I both agree that a date-only posted date field is the best
> solution, but we've always gotten substantial push-back from users so we've
> never changed it. Even the ability to edit the time, mentioned in comment
> 28, comes up from time to time. So if we set that aside for now, what do
> you think of using 11:00AM UTC instead of 00:00 Local, in particular
> changing in the middle of a release series?
>

Since there is no time-of-day reported, and it's not editable, no
time-of-day seems like the right representation. If we're dedicated to
storing time-of-day, we should be showing it and allowing it to be
editable. I'm guessing the argument for storing time of day, but not
showing it or allowing it to be edited is because 1) many users want time
of day, 2) no developers care enough to do the work to show and edit the
time of day, right?

Concerning changing to 1100 UTC, I take it that the current system has the
following flaw:
1) user A stores his file in Eastern Time (so that the transactions happen
at midnight in the morning of the transaction date), then later opens the
file in Central time and finds that the posting dates are off by one hour,
which is 2300 the previous day, so they appear to be off by a whole day?
In that case, moving to 1100 UTC (or anything UTC), and showing the date
UTC on the register has the effect of using a date-only representation.
Storing in 1100 UTC, and showing in local time on the register has the
problems you mentioned, but it seems a good deal better than having
problems between, e.g., EST and CST.