https://bugs.documentfoundation.org/show_bug.cgi?id=143508
--- Comment #5 from Mike Kaganski <[email protected]> --- (In reply to Wolfgang Jäger from comment #4) > And: What if the function only is a > subexpression, and the relevant result appears in a different cell... > Surprises to be expected anyway. This is irrelevant to this issue. > The inconcistency concerning TEXT() isn't actually important. This is not correct. The issue here is that there *is* a method *for spreadsheet author* to guarantee *predictable* results in their formulas using TEXT, if they use cell format locale carefully. They know exactly how the end result will look like, irrespective of the locale the program is configured for. (Or they may opt to use the defaults, so they really have the control.) To the contrary, when they use DATEVALUE, they are bound to the program-level settings, and there's no way to ensure predictable input string processing (e.g., when input format is known) independent of user settings. (Note that *displaying* the result of DATEVALUE is unrelated to the problem: here we *only* discuss ho can we control the *direct behavior* of mentioned functions [which in case of DATEVALUE is conversion from text to number], not some post-processing of the results.) No matter what one might think about the problematic status quo of date/time representations in spreadsheets (which exist of course), or in this world in general, the discussed inconsistency is a problem disallowing useful applications. -- You are receiving this mail because: You are the assignee for the bug.
