<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Clarify clock time (HH:MM, MM:SS, ...) and duration time ([HH]:MM, [MM]:SS, ...) formatting in help; (ignore the MM month vs minute discussion)" href="https://bugs.documentfoundation.org/show_bug.cgi?id=127170#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Clarify clock time (HH:MM, MM:SS, ...) and duration time ([HH]:MM, [MM]:SS, ...) formatting in help; (ignore the MM month vs minute discussion)" href="https://bugs.documentfoundation.org/show_bug.cgi?id=127170">bug 127170</a> from <a class="email" href="mailto:jarko@sortsk.pl" title="Jaromir / jarko@sortsk.pl <jarko@sortsk.pl>"> Jaromir / jarko@sortsk.pl</a> <pre>(In reply to Albrecht Müller from <a href="show_bug.cgi?id=127170#c15">comment #15</a>) > (In reply to Jaromir / <a href="mailto:jarko@sortsk.pl">jarko@sortsk.pl</a> from <a href="show_bug.cgi?id=127170#c14">comment #14</a>) > > In my opinion -45 minutes should be always treated as "-00:45" (that is > > [HH]:MM). > How would you then represent something like "1899-12-29 23:15:00" or - a > more common case - like "2020-04-23 19:33:05"? By setting zero point to "-9999.01.01 00:00:00" (or "-99999999.01.01....." - e.g. for professionals wanted "extended" calendar). Anyway, internally use only positive values. > > > Involving reference points makes a mess: you always have to > > remember your "startpoint". > This was never a problem for me: Not I have to remember the reference point > but the spreadsheet program has to know where it is. But I understand that > this may cause trouble as there are different conventions. How would you > define points in time without some reference point? See above. Universal reference point. > > > Yes, it is possible to maintain double (float/integer) operations for each > > time/date value. But for the price of unnecessary overloading. > I don't understand this argument: Depending on the context time may be seen > as continuous process or a sequence of countable ticks. So both a float and > an integer representation may be adequate. In the context of date and time > calculations the error recovery mechanism is not very complicated. Everything is possible. But - according to notes of Mr. Mike Kaganski - the speed is crucial for modern spreadsheets. That's why my objection. > > > Let's use it only in very situations: when backward compatibility is required. > I consider this a pretty important use case. If written on paper you can > read calculations that are hundreds of years old. How long should it be > possible to access contents of spreadsheets? I divide users into roughly two groups: those, who would maintain their calculations made many years ago, and those, who just start work with new data. The first group needs extra math processing, but the latter is free of that charge.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>