https://bugs.documentfoundation.org/show_bug.cgi?id=127476
--- Comment #11 from b. <newbie...@gmx.de> ---
sorry, i'm not convinced ...
there are two to three overall targets:
- excel conmpatibility,
- obeying standards,
just installed ex$el 2010 winx64 for a countercheck, results: year 2000, second
0, (month 1, day 1, hour 0, minute 0),
calc: year 1999, second 0, (month 12, day 31, hour 23, minute 59),
if calcs results are required by a standard ...
- change that standard, or
- produce results which are not! 59,9 seconds off,
(as @Eike said: 'Yes rounding SECOND() is odd, complains go to Excel', but then
either avoid ex$el behaviour, or copy it in full, not copy the odd thing reg.
'compatibility' and leave out the corrections necessary to deal with the crap)
if it's not possible to meet both targets (compatibility and standard)
something must decide ... imho 'usability', a program should work in a way and
produce results which are correct for and can be handeled by 'normal' users,
without exotic unversity grade to be happy about their special fp-knowledge.
for those users it's 'not so easy' to accept arbitrarely choosen different
handling of similar things, neither to understand the resulting calculation
errors.
either 'wall clock standard', a wall clock does not! show '00' for the seconds
at 59:59,9 minutes, it shows 59 seconds till the minute is full (as it shows 59
for the minute till the hour is full), OR! intelligent rounding, but no
mix-mess.
(a friend of mine often quoted: 'either consquent or inconsequent, but not this
or that as you like!')
the 'wall clock standard' is especially made for those stupid users who'd have
problems with rounded minutes? then we ought to give them 'wall clock standard'
for seconds too. and of course for milliseconds, microseconds, nanoseconds and
so on.
how do caesium clocks tick in their last digit? rounding?
or! we have to stick to compatibility, and round up.
excels results are kohärent within themself? and users can calculate with them,
former behaviour of calc was consistent in itself? and users could calculate
with the results?
and now we have something that fits to a 'standard', but breaks calculations in
a spreadsheet and nags users ... ??? that's not real progress.
rounding in stepped 'place value' systems with circulr iteration of the digits
is 'not so easy', you have to care for the carry, but 'the standard' is to take
the unrounded basic value, e.g. wednesday for '=weekday(43831,6;1)'? or 1 as a
answer to 'give me the tens digit of 315,6 please'?
if anyone (calc) deviates from that standard it should have good reasons, and
results consistent within themself. ex$el deviates in a consistent way, calc is
indifferent and deviating.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
