Business 'fancy date format'

Robert Fewell 14ubobit at gmail.com
Fri Nov 11 07:45:34 EST 2016


There is some thing else wrong with this and that is that the Locale and
UTC options are crossed.
Any way, what I thought I would do at some point is the following...
Sort above out.
Add an option "No Fancy Date" which would be the default and it will also
clear the KVP entries when selected
Keep the UTC option but rename it to "UTC - Coordinated Universal Time".
When there is no fancy date format for the report, use the one set in
Preferences/Date

Regards,
   Bob

On 10 November 2016 at 17:01, Geert Janssens <geert.gnucash at kobaltwit.be>
wrote:

> On Thursday 10 November 2016 07:16:42 you wrote:
> > > On Nov 10, 2016, at 5:09 AM, Geert Janssens
> > > <geert.gnucash at kobaltwit.be> wrote:>
> > > On Wednesday 09 November 2016 06:50:16 John Ralls wrote:
> > > > > On Nov 9, 2016, at 2:17 AM, Robert Fewell <14ubobit at gmail.com
> > > > > <mailto:14ubobit at gmail.com>> wrote:
> > > > >
> > > > > John,
> > > > >
> > > > > Yes this is master and the reports have been changed. On maint
> > > > > there
> > > > > is an option for 'Fancy Date Format' and the default is what I
> > > > > stated above so your date will be correct.
> > > > >
> > > > > So to me it looks like the following...
> > > > >
> > > > > The File/Properties/Business should be showing 'Locale' as the
> > > > > default and remove 'UTC' from the list. (it is not on the list
> > > > > in
> > > > > Preferences/Date) (gnc-default-strftime-date-format) should
> > > > > return
> > > > > a format based on 'Locale' These reports should test for a valid
> > > > > 'Fancy Date Format', if not, use the default one.
> > > > >
> > > > > If you agree I will add it to my pull request dealing with the
> > > > > report changes.
> > > >
> > > > Bob,
> > > >
> > > > Saying that the reports had changed got me to look at history,
> > > > which
> > > > reminded me that on maint the Fancy Date setting doesn't actually
> > > > work and that Geert fixed it in master last year. I think his idea
> > > > was that the user might want to have reports dated in UTC instead
> > > > of
> > > > the local time-zone, but I don't remember the reasoning. Perhaps
> > > > he
> > > > does. Until he chimes in let's leave it on the list.
> > >
> > > Just for kicks I tried to trace the UTC definition back in our code
> > > base. I lost the trail in the gnome2 merge in 2005. So it's been
> > > around for a while.
> > >
> > > The definition of this date format can presently be found in
> > > https://github.com/Gnucash/gnucash/blob/master/src/libqof/qof/gnc-da
> > > te.h#L109
> > > <https://github.com/Gnucash/gnucash/blob/master/src/libqof/qof/gnc->
> > date.h#L109>
> > >
> > > And a bit later in the enum there is an example:
> > > 2004-12-12T23:39:11Z
> > >
> > > It's the only of all the date formats that includes a time. All
> > > others are date only. I have no idea why this was added
> > > unfortunately. And given we are considering removing all time
> > > information from gnucash, I wonder if it's even useful to keep
> > > around for much longer.
> > We haven't before considered removing time information. We've been
> > discussing for a very long time indeed how to reconcile the way we
> > store posted-date as an arbitrary date-time with our users'
> > expectation that that date should be the same nominal value
> > regardless of time zone. Getting rid of time and therefore time zones
> > altogether and having only dates is an interesting idea. It would
> > permit simplifying a lot of code.
> >
> > That doesn't really bear on having an option to date a report with a
> > UTC date-time. I can't immediately think of a reason to do that*, but
> > if it's been around forever then we should ask for some user feedback
> > before removing it.
> >
> > Regards,
> > John Ralls
> >
> > * At least not in the context of what I understand of our users'
> > needs.
> In gnucash the fancy date format is only used on invoice reports and for
> printing checks. For
> invoices it looks rather odd to have the date contain time as well. At
> least I've never seen one.
>
> And as we're synthetically normalizing dates to 10'59. There doesn't seem
> to be much point in
> adding the time. Unless check printing uses the date-entered instead of
> date-posted ? I didn't
> check, mostly because I don't care *that* much right now.
>
> I think I'll just stop spending more time on this for now. The initial
> issue for this thread was
> what to do with some reports that fail if the fancy date was never set.
> Solving that is sufficient
> for me now.
>
> But yes, if we do want to consider removing the UTC date option, we should
> ask beforehand.
>
> Geert
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


More information about the gnucash-devel mailing list