Nathan Buchanan nbinont at gmail.com
Thu Jul 17 00:30:55 EDT 2008

On Wed, Jul 16, 2008 at 7:24 PM, Derek Atkins <warlord at mit.edu> wrote:

> Quoting Charles Day <cedayiv at gmail.com>:
> > On Wed, Jul 16, 2008 at 2:17 PM, Derek Atkins <warlord at mit.edu> wrote:
> > [snip]
> >
> >>
> >> Actually, except for GMT-12 or GMT+12, no, you do NOT need the time zone
> >> to figure out the date from 1200 UTC.   However as I've said now three
> >> times, GnuCash doesn't use 1200 UTC currently, it uses 0000 local, which
> >> (as I've said a half dozen times) I consider a bug that should get
> fixed.
> >>
> >
> > I don't see how 1200 UTC would work in New Zealand or any of the other
> > countries on GMT+12, not to mention Tonga. You enter a date of July 2,
> then
> > GnuCash converts it to July 2, 1200 UTC. Then when you close GnuCash and
> > reopen it, the date now displays as July 3 (July 2, 1200 UTC + 12 hours).
> So
> > this would actually goof up New Zealanders; even the ones who never leave
> > their time zone! Am I misunderstanding?
> * sigh *   Unfortunately no.  Doing a little research it appears that
> timezones go from GMT+14 to GMT-10.  At least I cannot find a GMT-11 or
> GMT-12 timezone.   But right now it is the same time, but one day apart
> at GMT+14 (e.g. Kiritimati, Christmas Islands) vs. GMT-10 (Hawaii).  Is
> there some (landed) part of the world at GMT-11 or GMT-12?
> Unfortunately that means there isn't really a single timestamp we could
> choose.  The best we could do is choose 10:01:00 GMT, which would give
> us the correct answer everywhere but at GMT+14.

I agree that the 00:00 timestamp is a bug, but the 12:00Z or 10:01:00Z
simply works around the bug for 90% of the use cases. From the perspective
of dealing with user's existing data, I think it would make more sense to
wait for a comprehensive solution so that we don't have to worry about data
conversion twice. (assuming, of course, that we don't decide that the 90%
solution is the comprehensive solution)


> > I think Graham's point about a distinction between the two types is
> > important. A date, which is all we allow the user to provide, represents
> a
> > time range. A timestamp represents a fixed point in time. If we are not
> > going to allow users to enter a timestamp, then we probably shouldn't be
> > converting it into one. On the other hand, if we are going to allow
> > timestamp entry then we have some code changes to think about (see my
> RFC).
> Well, I still believe that we SHOULD let users enter the timestamp.
> (I must've missed your RFC)
> -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
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

"Even if you are on the right track, you'll get run over if you just sit
there" - Will Rogers

More information about the gnucash-devel mailing list