> On Jun 19, 2016, at 6:25 PM, Aaron Laws <dartm...@gmail.com> wrote: > > On Sun, Jun 19, 2016 at 6:15 PM, John Ralls <jra...@ceridwen.us > <mailto:jra...@ceridwen.us>> wrote: > > > On Jun 19, 2016, at 1:07 PM, Christian Stimming <christ...@cstimming.de > > <mailto:christ...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
