https://bugs.documentfoundation.org/show_bug.cgi?id=136615
--- Comment #32 from Albrecht Müller <albrecht.muel...@astrail.de> --- (In reply to Eike Rathke from comment #31) > (In reply to Albrecht Müller from comment #29) > > @Eike Rathke: > > Rounding any day's 23:59:59.6 into the next day's 00:00:00 is related to > > another thing: Adding exactly one minute to another exact minute should > > always give two minutes – not sometimes one minute and sometimes two > > minutes. > I think you are mixing up things. Or at least the context and > conclusion/example doesn't make sense to me. > So let me explain this a little bit. I guess – please tell me if I am wrong – that one of the reasons why you don’t like Microsoft's approach to date and time arithmetic is that you think that a day change should occur exactly at midnight. If you want to have this property you have to use a round down strategy. Unfortunately there is no exact floating point representation for common time units shorter than a day such as hours, minutes, and seconds. For the sake of argument lets assume that the internal representation of 1 Minute is 1.1. Adding another minute to this gives 2.2. What the user sees if a round down strategy is used is 1 + 1 = 2. Fine. But lets assume that the internal representation is 0.9. So adding two minutes together gives 1.8. What the user sees now is 0 + 0 = 1. Not so good. The same thing using a rounding to the nearest strategy: No matter if the actual calculation is 1.1 + 1.1 = 2.2 or 0.9 + 0.9 = 1.8, in both cases the equation that shows the rounded values is 1 + 1 = 2. The downside of this rounding strategy is that values before midnight get rounded to the next day. Thus the day change is not exactly at midnight. I fear that you have invested a lot of time optimizing the use of the rounding to the nearest strategy built into the floating point arithmetic. You may have been able to eliminate the problem for some classes of calculations. But I assume that this work will not solve the underlying fundamental problem and therefore it will reappear if you use different examples, e.g. examples that contain multiplies of inexact time values. -- You are receiving this mail because: You are the assignee for the bug.
