Apache OpenOffice (AOO) Bugzilla – Issue 47906
Input mask for time and date formatted cells
Last modified: 2013-08-07 15:12:27 UTC
Would like the ability to pre-format date and time cells with the required "/" or ":" characters so that input from the 10-key will be sufficient to enter these values.
one for thew requirements team
Not only "/" and ":". I would rather say whatever character used with date and time, according to the language settings. I am Swedish and I use the ISO 8601 date format, which is supposed to be international standard... http://freedos-32.sourceforge.net/showdoc.php?page=standards#iso8601 Johnny
This should be modelled on the Form 'Pattern' field, which already provides masking in OOo. Unfortunately, 'Pattern' controls can't be linked to cells, so this doesn't provide a temporary workaround.
Is the following the same issue?: Calc operates in a strange way with the MM:SS.00 format. 2:23.45 is fine but 23.45 is not. It is not just that you have to type in 0:23.45 to get it right but that, if you do type in 23.45 it comes up with 48:00:00!
Advisor wrote: â€â€¦if you do type in 23.45 it comes up with 48:00:00!†I suppose you mean 18:00:00, which makes sense, since 23.45 (if decimal separator is â€.â€) means day 23.45 which is 23 days + 0.45 days. 0.45 days is 18 hours, hence 18:00:00. But I agree that an input mask would be very useful, especially when entering a lot of data in many fields. Typing 2345 is a lot faster than 23:45, and I really mean a LOT faster. At least with a Swedish keyboard layout (: = Shift+.).
@advisor: To clarify, this bug is an RFE to have these numbers formatted as follows: "ab" formatted as "ab:00" "abc" formatted as "0a:bc" "abcd" formatted as "ab:cd" This is assuming the "hh:mm" format, and of course as guraknugen pointed out it should be fit to what ever format is configured. Your comment mentions that data is not only appearing in the wrong format, it is being interpreted incorrectly by OOo. I would say that, as you describe it, that is a dataloss issue and in fact makes this RFE a severe bug. Can a dev elaborate on whether to change the Issue Type to Bug and raise the Priority as this is a dataloss issue? Thanks.
Fortunately there is no data loss. Going back to Advisor's issue of 23.45 becoming 48:00.00, Guraknugen is correct in saying that Calc get's it right, but the explanation is not quite correct (although it looks correct at first - 18 hours is 3/4 of one day and 45 minutes is 3/4 of one hour - an easy to do pattern matching mistake). Using a MM:SS.00 format this is correct. 0.45 of 1 day (24 hours) is 10.8 hours or 10 hours 48 minutes, or 48:00.00 as formatted. If you enter 23.45 into a field formatted as HH:MM:SS.00 you get 562:48:00.00. This is also correct.