https://bugs.documentfoundation.org/show_bug.cgi?id=136615
--- Comment #47 from Albrecht Müller <albrecht.muel...@astrail.de> --- (In reply to Eike Rathke from comment #46) > ... > > I want to understand this clearly because I think > > that this half second is related to your comment #35. > ? I don't think so. > ... In your comment 35 I found: > The real solution would be to get rid of that and use a proper DateTime > type instead and convert to floating point only when needed, e.g. when > exporting to Excel file formats or calculations require it or if a > floating point display is requested. I wondered what the purpose of using a “proper DateTime type” could be. I know that you think Microsoft’s way of doing date and time calculations is wrong and that you introduced a distinction between wall clock time and durations. Thus I thought that this type should fix some of the limitations of Microsoft’s date and time arithmetic, e.g. allow the handling of the transition between daylight saving time and standard time, support durations in the sense of ISO 8601 (see https://en.wikipedia.org/wiki/ISO_8601#Durations) etc. This was the motivation behind my comment 36 which you flagged as “off-topic”. My guess about your intentions was obviously wrong. So I assume now that the concept behind your DateTime type is essentially the same as the idea of discrete time which I tried to explain in comment 37. The common point is the use of an arithmetic that allows to do exact calculations. The difference is that Microsoft always converts between floating point and the discrete time model. As a consequence you will never see Microsoft’s discrete time model – all you see are floating point values. The discrete time model is used “under the hood” only. The critical point is how to convert between floating point values and your DateTime type or Microsoft’s discrete time model. It may be surprising that this conversion can be done quite reliably. The key to understand this is that the round off errors are usually pretty small and you probably will never see situations where these errors are equal to or greater than ½ second. If the round off errors stay below ½ second then rounding to the nearest second always finds the correct exact second. -- You are receiving this mail because: You are the assignee for the bug.
