On Wed, Jul 16, 2008 at 7:24 PM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> Quoting Charles Day <[EMAIL PROTECTED]>: > > > On Wed, Jul 16, 2008 at 2:17 PM, Derek Atkins <[EMAIL PROTECTED]> 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) Nathan > > > > 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 > [EMAIL PROTECTED] PGP key available > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
