Re: time_t
Stuart D. Gathman wrote: ts:date2008-04-10 18:02:00 -0400/ts:date The issue here isn't the data file (which I assumed we all agreed included the needed info). The issue is that loading the nice ascii timestamp with timezone into just a time_t field in memory (even a 64 bit one) loses critical info: the timezone. Java code has faced this exact problem for many years (java.util.Date isn't a date, but a timestamp with no timezone information), and as a result JSR310 has been proposed, which will see a whole new date and calendar library in Java targeted for JDK7 (as I understand). The work is based on work by the same people who created a date and time handling library called Joda Time: http://joda-time.sourceforge.net/ Gnucash suffers the same date problems as do applications that use the current built in Java date formatting. For those who don't fully understand the implications of date handling, comparing Joda Time to java.util.Date and java.util.Calendar should give an idea of the extent of the problem. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: time_t
Derek Atkins wrote: Try the string 2008-04-11 00:02:00 +0200. Same timestamp. Different date. * sigh * Are you intentionally ignoring my repeated statement that we need to CHANGE GNUCASH TO USE 1200Z? No, read back what you said, which was For example, what's the difference between 2008-04-10 18:02:00 -0400 and 2008-04-10 15:02:00 -0700? I would argue that there *is* no difference. Both timestamps are talking about the exact same time. And hey look, they both say 2008-04-10. You are claiming, in this sentence, that the change in timezone doesn't cause a change in date. I have showed your assertion to be false for the example you gave. Nah, it's pretty easy to be consistent. Indeed, GnuCash *IS* already very consistent on this already. I have hunted down many bugs, and I can identify bugs that have a high risk of coming back, this is one of them. Remember my point about engineering finance software very carefully? Avoiding bug traps like this is one way you do this. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Transaction timestamps are a design flaw (was: time_t)
Am Dienstag, 15. Juli 2008 21:35 schrieb Derek Atkins: Quoting Graham Leggett [EMAIL PROTECTED]: If I don't do this, transactions report themselves as being one day early, so transactions on the first of the month suddenly appear on the last day of last month, which sends my VAT returns into a spin. That's because transactions are set at midnight instead of, say, noon. I think this is being caused by dates that are actually dates and not times, being stores as times. You think incorrectly. There are LOTS of reasons to store times in transactions. There ARE timestamps in the real world. And there are reasons that some people want to actually put time stamps into transactions, too (see bug #89439). I'm not saying that there isn't a bug here, just that your reasoning is flawed. I disagree with Derek here. Instead, I agree transactions should store a *date* and not a timestamp as the piece of information that is presented to the user. And I agree it's a design flaw of gnucash that we don't have a separate data type exactly for such a *date* as opposed to a timestamp. (The date_entered [sic!] timestamp, on the other hand, describes the point in *time* when this was entered, where a timestamp is the perfectly reasonable representation.) I fully agree with Graham's reasoning here - I've seen my transactions shifting through the days as I switched timezones, and it's a mess. I disagree this issue would have gone away by using the noon timestamp, as UTC+13 (or whatever) exists and has already been mentioned here. One place that IMHO solves this whole date vs. timestamp issue correctly (eventually) is the boost library and its date_time sub-library, see http://www.boost.org/doc/libs/1_35_0/doc/html/date_time.html , where they even enforce the distinction between dates and times quite rigidly through C++ constructor constraints. In effect, the programmer really has to think about whether one wants a date or a time point here. All financial bookkeeping that gnucash has encountered so far maps transactions to one particular day. This is what the internal types should reflect, and the fact that we don't do this is still a design flaw although a very old one. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: RFC: Timestamps/timezones proposal
Am Mittwoch, 16. Juli 2008 22:04 schrieb Charles Day: OK, here's an idea. I'm interested in seeing the reaction. Maybe it's stupid, maybe not. 1. Store transaction timestamps in UTC. Transactions currently store two timestamps, see http://svn.gnucash.org/docs/HEAD/structtransaction__s.html Timespec date_entered; /* date register entry was made */ Timespec date_posted; /* date transaction was posted at bank */ I assume we're discussion the date_posted here. For the reasons that have been discussed in the Re: time_t thread in length, I don't think storing this in UTC really solves the problem at hand. Instead, I propose a different approach: Change the date_entered field of a transaction into a GDate. 2. Set a timezone for each account. I think the case of different account timezones inside the same gnc_book is an extreme corner case. Wait a second - that's the European point of view. Is this different in North America? From a European point of view, I think the UI necessary to handle one timezone per account is an insane overkill that no one will understand at all. Instead, if at all, a book should store one timezone and that's it. 3. In account registers, the transaction date is displayed according to that account's timezone. If date_posted were a GDate, the transaction date is simply that date. 4. In account registers, entering/altering a transaction date is always done in terms of that account's timezone. Yes. 5. Add report options allowing the user to pick a reporting time and timezone I don't think this could be presented in a UI that isn't grossly misunderstandable to the vast majority of users (though again, that's the point of view of contries which don't have more than one timezone). Instead I would simply choose the local timezone for each report, as it is currently. 6. Allow users to specify the time of day for transactions. (Perhaps optional.) No, even though this is being asked for in that very old bug, I don't think this will improve the situation, let alone the UI. For example, as I move around the globe, altering my computer's timezone wouldn't affect how transactions are displayed This, as everyone confirmed so far, is still clearly a bug and needs to be fixed in any case. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: time_t
Stuart D. Gathman wrote: The issue here isn't the data file (which I assumed we all agreed included the needed info). The issue is that loading the nice ascii timestamp with timezone into just a time_t field in memory (even a 64 bit one) loses critical info: the timezone. On POSIX systems, and on Windows as far as I can see, time_t contains seconds since midnight, Jan 1 1970 UTC, so a timezone is in there. GnuCash's timezone problem isn't time_t's fault. http://msdn.microsoft.com/en-us/library/1f4c8f33(VS.80).aspx http://en.wikipedia.org/wiki/Time_t ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: RFC: Timestamps/timezones proposal
On Wed, Jul 16, 2008 at 9:07 PM, Nathan Buchanan [EMAIL PROTECTED] wrote: Hi! On Wed, Jul 16, 2008 at 4:04 PM, Charles Day [EMAIL PROTECTED] wrote: OK, here's an idea. I'm interested in seeing the reaction. Maybe it's stupid, maybe not. I havn't looked at the time code used in gnucash, so whatever I say is entirely as an observer here. Generally I like the idea, though I don't know the work involved. 1. Store transaction timestamps in UTC. This seems sane to me. I would assume they'd be stored as ISO8601 strings or as seconds from the epoch (though that's somewhat less readable). In theory, you could store it as any ISO8601 string (similar to what we have now, I think), but this would only indicate a point in time. The timezone, while useful in converting to UTC, would otherwise be meaningless. 2. Set a timezone for each account. ok. What happens when the user changes an account's timezone? Do all the timestamps for that account get updated? Or do the timestamps remain the same, but the time displayed potentially changes? Timestamps remain the same and the value displayed changes. Also, how would we deal with a transfer from an account A in timezone A to an account B in timezone B? What time (hour) would get assigned? Then what happens when the user decides to change the timezone for account A? If you enter the transfer in register A, you are entering in terms of A's timezone. If you enter it in B, you're using B's timezone. The hour could be defaulted by a preference unless the user want to actually enter a different one (which I think should be allowed; otherwise I see no point using timestamps at all). We would simply have to decide on these things and document them clearly. 3. In account registers, the transaction date is displayed according to that account's timezone. 4. In account registers, entering/altering a transaction date is always done in terms of that account's timezone. sounds good. 5. Add report options allowing the user to pick a reporting time and timezone ok. 6. Allow users to specify the time of day for transactions. (Perhaps optional.) nice, but would probably not get used way to much - we would need to pick a sane default (which we would have to do anyway) Exactly. We pick a sane default, but allow users to enter a different one if they choose. From an implementation standpoint, I believe collecting the time data is actually easy to do; the code to support that is already there but not activated in registers. Nathan Suppose this was already done... How would it help you out or screw you up? I have accounts in several timezones, and I can see a few ways that this would help me already compared to the status quo. For example, as I move around the globe, altering my computer's timezone wouldn't affect how transactions are displayed Cheers, Charles -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: RFC: Timestamps/timezones proposal
On Thu, Jul 17, 2008 at 1:37 AM, Christian Stimming [EMAIL PROTECTED] wrote: Am Mittwoch, 16. Juli 2008 22:04 schrieb Charles Day: OK, here's an idea. I'm interested in seeing the reaction. Maybe it's stupid, maybe not. 1. Store transaction timestamps in UTC. Transactions currently store two timestamps, see http://svn.gnucash.org/docs/HEAD/structtransaction__s.html Timespec date_entered; /* date register entry was made */ Timespec date_posted; /* date transaction was posted at bank */ I assume we're discussion the date_posted here. For the reasons that have been discussed in the Re: time_t thread in length, I don't think storing this in UTC really solves the problem at hand. Instead, I propose a different approach: Change the date_entered field of a transaction into a GDate. I'm not trying to ignore the GDate solution. I just want to consider any alternatives so we can compare. Using GDate would of course be much better than the status quo, but it also removes the option to capture the posting time of day. The other possible option is an improved design around timestamps, so I want explore that option and see what conclusions can be reached, even if the conclusion is timestamps won't work. 2. Set a timezone for each account. I think the case of different account timezones inside the same gnc_book is an extreme corner case. Wait a second - that's the European point of view. Is this different in North America? From a European point of view, I think the UI necessary to handle one timezone per account is an insane overkill that no one will understand at all. Instead, if at all, a book should store one timezone and that's it. There can be a preference for default time zone. Only users that actually have a need for timezone differences would need to mess with per-account -settings. Storing one timezone per book could be OK too, but users with accounts in a variety of timezones (like me) might be interested in more flexibility. 3. In account registers, the transaction date is displayed according to that account's timezone. If date_posted were a GDate, the transaction date is simply that date. I get that, but if I transfer funds from US to Australia, in one account the date will be wrong most of the time. Going the other way, what if I transfer some cash from Australia to the US, then fly to the US (arriving before I left, according to the calendar) then immediately spend the money? Depending on how you choose to use GDates, I could be spending the money in the US before I even transfer it there. Obviously the way around that is to just let the date be off in one account. (I'm used to that sort of fudging by now, and it doesn't bother me.) 4. In account registers, entering/altering a transaction date is always done in terms of that account's timezone. Yes. 5. Add report options allowing the user to pick a reporting time and timezone I don't think this could be presented in a UI that isn't grossly misunderstandable to the vast majority of users (though again, that's the point of view of contries which don't have more than one timezone). Instead I would simply choose the local timezone for each report, as it is currently. Use the same default as the accounts. Most users won't know/care, but offer the choice to those that do. 6. Allow users to specify the time of day for transactions. (Perhaps optional.) No, even though this is being asked for in that very old bug, I don't think this will improve the situation, let alone the UI. Personally, I don't have much need for entering a variety of times. But the UI doesn't need to visibly change much. I would suggest that the register display stay the same, and those who want to see or enter a time of day could do so by clicking the drop-down button in the register's date field (the pop-up calendar also allows time entry, if we choose to allow it). On reports, display of time of day would be off by default. For example, as I move around the globe, altering my computer's timezone wouldn't affect how transactions are displayed This, as everyone confirmed so far, is still clearly a bug and needs to be fixed in any case. Regards, Christian -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: time_t
Glen Ditchfield wrote: Stuart D. Gathman wrote: The issue here isn't the data file (which I assumed we all agreed included the needed info). The issue is that loading the nice ascii timestamp with timezone into just a time_t field in memory (even a 64 bit one) loses critical info: the timezone. On POSIX systems, and on Windows as far as I can see, time_t contains seconds since midnight, Jan 1 1970 UTC, so a timezone is in there. GnuCash's timezone problem isn't time_t's fault. No, a time_t only stores a point in absolute (well, earth relative) time. It does not record *where* (i.e. what timezone) that point in time occured. In particular, it does not record what the *date* was at that point in time. There are in general two possible dates for a given time_t depending on the timezone, and in some obscure cases, three. The timezone is not in there. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: time_t
Nathan Buchanan wrote: 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 Not only that, but if you force the time of day in each timestamp to 12:00Z, then you no longer have a timestamp, but a complicated and difficult to use date type. You can't even subtract these ersatz date types to get days between dates. (No dividing by 24*60*60 doesn't work - don't forget DST, etc). There is *far* less code overall to just store dates (ideally a day number of some sort) where you want dates (i.e. where you would force the TOD to 12:00), and store timestamps where you need timestamps (stock prices, etc). I've been dealing with this issue for 30 years, and seen the same mistake made over and over. Similar to trying to do accounting with binary floating point. Yes, you can make it work by rounding every other line of code. But it is butt ugly, slow, and error prone. And usually doesn't actually work in any given application (invoice totals sometimes off by a penny). ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
The beauty of open source
For what proprietary accounting products do you get to have a long and heated argument with the developers about the best way to store dates? Maybe if you are their biggest customer with a multi-million dollar contract on the line. I just wanted to take time out from the argument to say THANK YOU for an excellent product that anyone can participate in. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: time_t
On Thu, Jul 17, 2008 at 9:46 AM, Stuart D. Gathman [EMAIL PROTECTED] wrote: Nathan Buchanan wrote: 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 Not only that, but if you force the time of day in each timestamp to 12:00Z, then you no longer have a timestamp, but a complicated and difficult to use date type. You can't even subtract these ersatz date types to get days between dates. (No dividing by 24*60*60 doesn't work - don't forget DST, etc). There is *far* less code overall to just store dates (ideally a day number of some sort) where you want dates (i.e. where you would force the TOD to 12:00), and store timestamps where you need timestamps (stock prices, etc). I've been dealing with this issue for 30 years, and seen the same mistake made over and over. Similar to trying to do accounting with binary floating point. Yes, you can make it work by rounding every other line of code. But it is butt ugly, slow, and error prone. And usually doesn't actually work in any given application (invoice totals sometimes off by a penny). Stuart, I would be interested in your reaction to my RFC on a timestamp implementation. Other than ease-of-use issues, is there a situation in which the RFC's proposed way of using timestamps would be detrimental compared to using a date alone? Thanks, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: time_t - When does it break?
Charles Day wrote: On Thu, Jul 17, 2008 at 9:46 AM, Stuart D. Gathman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Nathan Buchanan wrote: 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 Not only that, but if you force the time of day in each timestamp to 12:00Z, then you no longer have a timestamp, but a complicated and difficult to use date type. You can't even subtract these ersatz date types to get days between dates. (No dividing by 24*60*60 doesn't work - don't forget DST, etc). I would be interested in your reaction to my RFC on a timestamp implementation. Other than ease-of-use issues, is there a situation in which the RFC's proposed way of using timestamps would be detrimental compared to using a date alone? The way gnucash works currently is perfectly fine - *provided* you only ever use one timezone. This covers the vast majority of users. The systems I have had to repair date logic for had worked perfectly for years - but then the company expanded to have branches in multiple timezones. Suddenly, all hell breaks loose. Imagine for a moment that gnucash didn't store currency with transaction amounts. This works perfectly fine as long as you only ever use one currency. This would be fine for almost all US users, for instance. Now imagine trying to support multiple currencies without actually storing the currency with the amounts. :-) As I understand your proposal, it would use localtime as if it were GMT time. I.e., take the local time, replace the timezone with GMT, and convert to time_t. I have used that technique myself in repair work. It solves date compatibility between timezones. You can recover the actual timestamp if you can infer the timezone somehow. However, it requires lots of comments to explain to code maintainers so they don't screw things up. No, it is not a mistake when we replace the timezone with GMT... I created a new type for such timestamps to help prevent confusion with real time_t. It still is complicated to do basic date arithmetic. The only redeeming value is that you can drop it into an existing database without changing too much code if you do it right. If you have to anything funky to time_t to make it work right (force time of day to 12:00Z, pretend localtime is really GMT, etc) because what you really needed was a date type, and you don't have to interface with existing databases or code that can't be fixed, then the sensible thing to do is use a date type. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: time_t - When does it break?
On Thu, Jul 17, 2008 at 10:20 AM, Stuart D. Gathman [EMAIL PROTECTED] wrote: Charles Day wrote: On Thu, Jul 17, 2008 at 9:46 AM, Stuart D. Gathman [EMAIL PROTECTED]mailto: [EMAIL PROTECTED] wrote: Nathan Buchanan wrote: 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 Not only that, but if you force the time of day in each timestamp to 12:00Z, then you no longer have a timestamp, but a complicated and difficult to use date type. You can't even subtract these ersatz date types to get days between dates. (No dividing by 24*60*60 doesn't work - don't forget DST, etc). I would be interested in your reaction to my RFC on a timestamp implementation. Other than ease-of-use issues, is there a situation in which the RFC's proposed way of using timestamps would be detrimental compared to using a date alone? The way gnucash works currently is perfectly fine - *provided* you only ever use one timezone. This covers the vast majority of users. The systems I have had to repair date logic for had worked perfectly for years - but then the company expanded to have branches in multiple timezones. Suddenly, all hell breaks loose. Imagine for a moment that gnucash didn't store currency with transaction amounts. This works perfectly fine as long as you only ever use one currency. This would be fine for almost all US users, for instance. Now imagine trying to support multiple currencies without actually storing the currency with the amounts. :-) As I understand your proposal, it would use localtime as if it were GMT time. I.e., take the local time, replace the timezone with GMT, and convert to time_t. The basic idea is that in an account register the user enters a date and time of day (or accepts the default time of day) in terms of that account's timezone. When you view that transaction in another register that has been set to a different timezone, the date and time is displayed accordingly. For example, if you specify July 7, 2008 13:03 in a UTC+11 register, then viewing that transaction in a UTC-7 register would show July 6, 2008 18:03. (If I did the math right.) There is no pretending involved. I suggest that GnuCash would write the timestamp to files in UTC, but only by converting first (July 7, 2008 02:03). GnuCash really could write the date and time to the file in any time zone, as long as the time zone was saved too. I have used that technique myself in repair work. It solves date compatibility between timezones. You can recover the actual timestamp if you can infer the timezone somehow. However, it requires lots of comments to explain to code maintainers so they don't screw things up. No, it is not a mistake when we replace the timezone with GMT... I created a new type for such timestamps to help prevent confusion with real time_t. It still is complicated to do basic date arithmetic. The only redeeming value is that you can drop it into an existing database without changing too much code if you do it right. If you have to anything funky to time_t to make it work right (force time of day to 12:00Z, pretend localtime is really GMT, etc) because what you really needed was a date type, and you don't have to interface with existing databases or code that can't be fixed, then the sensible thing to do is use a date type. -Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: time_t - When does it break?
Charles Day wrote: The basic idea is that in an account register the user enters a date and time of day (or accepts the default time of day) in terms of that account's timezone. When you view that transaction in another register that has been set to a different timezone, the date and time is displayed accordingly. For example, if you specify July 7, 2008 13:03 in a UTC+11 register, then viewing that transaction in a UTC-7 register would show July 6, 2008 18:03. (If I did the math right.) Well, that approach obviously doesn't solve the date compatibility issue. To even be usable, the register would have to display the timezone. There is no pretending involved. I suggest that GnuCash would write the timestamp to files in UTC, but only by converting first (July 7, 2008 02:03). That makes the situation even worse than it is now by discarding the timezone info in the datafile. GnuCash really could write the date and time to the file in any time zone, as long as the time zone was saved too. That is what it does now. The current issue is how it handles dates/timestamps in memory. The datafile is fine. To beat the currency analogy to death, the way gnucash currently works is like converting all monetary amounts to one gobal currency preference, say USD. This mostly works, but your invoices in Pesos don't add up! The pretend localtime is GMT approach is like storing Pesos as is without converting. All the invoices add up, but whenever dissimilar currencies are combined, the code has to be careful to convert first. Converting requires that the currency was stored somewhere else - perhaps in the customer record. This works, but storing the currency with each amount is less error prone. A simple workaround. Since gnucash works fine within one timezone, why should it be fixed at all? The only people to care are jetsetters who travel between timezones and change the timezone on their laptop accordingly. One workaround for jetsetters is to wrap gnucash in a script that sets the TZ environment variable to a fixed value - say their home timezone. This prevents all date problems and accurately records timestamps. (The user has to remember to enter any time of day info in their home timezone, and that timezone should be displayed in the UI as a reminder.) The only thing not recorded is which timezone you were in when the transactions were recorded. Big deal. So add transaction timezone as a global preference, and the immediate problem is fixed. If people actually need to track which timezone they were in, they probably really want to track exactly *where* they were - not just the time zone, and gnucash could be extended to record location. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: RFC: Timestamps/timezones proposal
On 7/17/08, Charles Day [EMAIL PROTECTED] wrote: On Wed, Jul 16, 2008 at 9:07 PM, Nathan Buchanan [EMAIL PROTECTED] wrote: Hi! On Wed, Jul 16, 2008 at 4:04 PM, Charles Day [EMAIL PROTECTED] wrote: OK, here's an idea. I'm interested in seeing the reaction. Maybe it's stupid, maybe not. I havn't looked at the time code used in gnucash, so whatever I say is entirely as an observer here. Generally I like the idea, though I don't know the work involved. 1. Store transaction timestamps in UTC. This seems sane to me. I would assume they'd be stored as ISO8601 strings or as seconds from the epoch (though that's somewhat less readable). In theory, you could store it as any ISO8601 string (similar to what we have now, I think), but this would only indicate a point in time. The timezone, while useful in converting to UTC, would otherwise be meaningless. 2. Set a timezone for each account. ok. What happens when the user changes an account's timezone? Do all the timestamps for that account get updated? Or do the timestamps remain the same, but the time displayed potentially changes? Timestamps remain the same and the value displayed changes. Also, how would we deal with a transfer from an account A in timezone A to an account B in timezone B? What time (hour) would get assigned? Then what happens when the user decides to change the timezone for account A? If you enter the transfer in register A, you are entering in terms of A's timezone. If you enter it in B, you're using B's timezone. The hour could be defaulted by a preference unless the user want to actually enter a different one (which I think should be allowed; otherwise I see no point using timestamps at all). ok, though what happens when the user decides to change the timezone for account A? (eg. I ask the bank to transfer my account from their Saint John's branch to their Vancouver branch, 5 timezones apart?) What happens to the timestamps and dates displayed then? Nathan We would simply have to decide on these things and document them clearly. 3. In account registers, the transaction date is displayed according to that account's timezone. 4. In account registers, entering/altering a transaction date is always done in terms of that account's timezone. sounds good. 5. Add report options allowing the user to pick a reporting time and timezone ok. 6. Allow users to specify the time of day for transactions. (Perhaps optional.) nice, but would probably not get used way to much - we would need to pick a sane default (which we would have to do anyway) Exactly. We pick a sane default, but allow users to enter a different one if they choose. From an implementation standpoint, I believe collecting the time data is actually easy to do; the code to support that is already there but not activated in registers. Nathan Suppose this was already done... How would it help you out or screw you up? I have accounts in several timezones, and I can see a few ways that this would help me already compared to the status quo. For example, as I move around the globe, altering my computer's timezone wouldn't affect how transactions are displayed Cheers, Charles -Charles -- 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
Re: RFC: Timestamps/timezones proposal
On Thu, Jul 17, 2008 at 11:22 AM, Nathan Buchanan [EMAIL PROTECTED] wrote: On 7/17/08, Charles Day [EMAIL PROTECTED] wrote: On Wed, Jul 16, 2008 at 9:07 PM, Nathan Buchanan [EMAIL PROTECTED] wrote: Hi! On Wed, Jul 16, 2008 at 4:04 PM, Charles Day [EMAIL PROTECTED] wrote: OK, here's an idea. I'm interested in seeing the reaction. Maybe it's stupid, maybe not. I havn't looked at the time code used in gnucash, so whatever I say is entirely as an observer here. Generally I like the idea, though I don't know the work involved. 1. Store transaction timestamps in UTC. This seems sane to me. I would assume they'd be stored as ISO8601 strings or as seconds from the epoch (though that's somewhat less readable). In theory, you could store it as any ISO8601 string (similar to what we have now, I think), but this would only indicate a point in time. The timezone, while useful in converting to UTC, would otherwise be meaningless. 2. Set a timezone for each account. ok. What happens when the user changes an account's timezone? Do all the timestamps for that account get updated? Or do the timestamps remain the same, but the time displayed potentially changes? Timestamps remain the same and the value displayed changes. Also, how would we deal with a transfer from an account A in timezone A to an account B in timezone B? What time (hour) would get assigned? Then what happens when the user decides to change the timezone for account A? If you enter the transfer in register A, you are entering in terms of A's timezone. If you enter it in B, you're using B's timezone. The hour could be defaulted by a preference unless the user want to actually enter a different one (which I think should be allowed; otherwise I see no point using timestamps at all). ok, though what happens when the user decides to change the timezone for account A? (eg. I ask the bank to transfer my account from their Saint John's branch to their Vancouver branch, 5 timezones apart?) What happens to the timestamps and dates displayed then? The timestamps don't change. Only the value displayed. Nathan We would simply have to decide on these things and document them clearly. 3. In account registers, the transaction date is displayed according to that account's timezone. 4. In account registers, entering/altering a transaction date is always done in terms of that account's timezone. sounds good. 5. Add report options allowing the user to pick a reporting time and timezone ok. 6. Allow users to specify the time of day for transactions. (Perhaps optional.) nice, but would probably not get used way to much - we would need to pick a sane default (which we would have to do anyway) Exactly. We pick a sane default, but allow users to enter a different one if they choose. From an implementation standpoint, I believe collecting the time data is actually easy to do; the code to support that is already there but not activated in registers. Nathan Suppose this was already done... How would it help you out or screw you up? I have accounts in several timezones, and I can see a few ways that this would help me already compared to the status quo. For example, as I move around the globe, altering my computer's timezone wouldn't affect how transactions are displayed Cheers, Charles -Charles -- 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
Re: time_t - When does it break?
Charles Day wrote: No, the transaction timestamp is stored, denoting the precise point in time at which the transaction posted. The time zone is only needed when converting to a date or time of day, and for that you have the user's preferences (a default display time zone, a time zone per account register, and a reporting time zone.) Repeat after me: timestamps do not store date. Timestamps do not store date. Your own example shows that timestamps do not store the date. The date changes when the user changes timezone!!! As you just said above: The time zone is only needed when converting to a date That is precisely the problem. The time zone is needed when converting to a date or time of day. Is the problem that people don't think dates are important in accounting? Then why have the user enter a date ??? Having a preference for a single time zone just means ignoring the OS time zone. If we were going to do this, then why even offer users an option, or save it? The GnuCash developers could just pick a time zone at random and go with that. As long as only dates were ever displayed, that would work fine (other than being kludgy, complicated and slow compared to storing dates) . But some modules, like stock prices, need actual timestamps. And displaying those in an arbitrary gnucash timezone would be highly confusing to the end user. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: time_t
I've read most but not all of the many messages in the two threads on this topic. It is clear that there is a lot of passion around the issue. From my (end-user) perspective, I agree with (I think) Graham that the transaction date that displays in the register should be a date-only entry. I say this because from my perspective, I have transactions with a date only; I write my checks with a date only, and my bank statement has date-only. So this entry should be date-only. This date would be set once and would not fluctuate with the machine's timezone. I think, however, a universal timestamp value is critical for recordkeeping purposes within the accounting system (i.e., Gnucash itself). Such a timestamp could presumably also serve the purpose of sorting transactions in the register. As an absolute in time value, it would change as the machine's timezone changed. It seems to me that separating the different functions of this datum into different spots might help the system perform more reliably. David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: time_t - When does it break?
As a retired pro who has debugged many date errors in my day I really have to side with Stuart here. Michael D Novack, FLMI ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: time_t - When does it break?
I kind of understand where Stuart is going with this. There are a lot of parallels. The currency example is one. From a programming perspective, storing strings without an encoding is another. Essentially to know the real value you need to know another piece of metadata. Stuart, I'm curious though, and maybe you can fill me in, is the reason that the timestamp is important that, from an accounting standpoint, the transaction occurred on the day (in the timezone) that it was entered into the register? Meaning that the date is June 6 because it was entered in Timezone A even though that same time was June 7 in timezone B? So it's June 6 regardless of timezone. In other words, the timezone in which it was entered needs to be stored to figure out what day it was entered? Otherwise, wouldn't the local timezone be enough to serve as metadata when converting to a date? Ian 2008/7/18 Stuart D. Gathman [EMAIL PROTECTED]: Charles Day wrote: No, the transaction timestamp is stored, denoting the precise point in time at which the transaction posted. The time zone is only needed when converting to a date or time of day, and for that you have the user's preferences (a default display time zone, a time zone per account register, and a reporting time zone.) Repeat after me: timestamps do not store date. Timestamps do not store date. Your own example shows that timestamps do not store the date. The date changes when the user changes timezone!!! As you just said above: The time zone is only needed when converting to a date That is precisely the problem. The time zone is needed when converting to a date or time of day. Is the problem that people don't think dates are important in accounting? Then why have the user enter a date ??? Having a preference for a single time zone just means ignoring the OS time zone. If we were going to do this, then why even offer users an option, or save it? The GnuCash developers could just pick a time zone at random and go with that. As long as only dates were ever displayed, that would work fine (other than being kludgy, complicated and slow compared to storing dates) . But some modules, like stock prices, need actual timestamps. And displaying those in an arbitrary gnucash timezone would be highly confusing to the end user. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
