Transaction Posted Time

John Ralls jralls at ceridwen.us
Sun Jun 19 23:12:09 EDT 2016


> On Jun 19, 2016, at 6:25 PM, Aaron Laws <dartme18 at gmail.com> wrote:
> 
> On Sun, Jun 19, 2016 at 6:15 PM, John Ralls <jralls at ceridwen.us <mailto:jralls at ceridwen.us>> wrote:
> 
> > On Jun 19, 2016, at 1:07 PM, Christian Stimming <christian at cstimming.de <mailto: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.

Aaron,

Actually it's worse than that. Store a transaction in the summer, then look at it in the winter and it's the day before.

The reason for not changing it to date-only now is file compatibility. A newly stored file would have no time part, and that would fail to load in 2.6.12. If we change it now to scrub to 1100Z (sailor/flyer/military for 11:00AM UTC) then it will continue to load on older versions and will magically not flip dates even on those older versions for all but the few users in the time zones I mentioned at the start of the thread. This would also be a good time to change the input code to not blow up if there's no time part, but instead to set a timespec at 1100Z on the date indicated.

Regards,
John Ralls






More information about the gnucash-devel mailing list