Issue 104504

I'm tempted to resolve this as INVALID or WONTFIX - the scenario you describe is
not really what the formatted/time field is designed for. Instead, you should
use a pattern field, with an "Edit mask" of NNLNN, and a "Literal mask" of
"__:__". If you then set the "Strict format" property to "Yes", then the colon
will always be displayed, but the user does not need to enter it, but can simply
type the four numbers which comprise the time.

fs, I appreciate your time and ask you to give me just a little more.

Firstly, I have checked this behavior and it appears to be consistant in linux
(gentoo and openSuSE 11.1) using OOo 3.1.0m11.

Secondly, this is the method

Open base -> create form -> insert Formatted Field -> open Properties ->
select Formatting -> set Catagory to Time, format to 13:37 (24 hr time)
and select "Ok" -> set Value Min to 00:00 and Value Max to 23:59 ->
leave design mode and enter values.

OR

Open base -> create form -> insert Time Field -> Strict format to YES,
Time Min to 00:00:00, Time Max to 23:59:00, and Time Format to 13:45 ->
leave design mode and enter values

You will find that my previous description of the result is accurate.

It appears that both tools are designed (by means of the formatting available in
the default control) to accomodate this, and other, data sets.

With that said, I appreciate the alternate method that you have provided, and we
will impliment it here. However, my end user man not always be well educated in
how to use the frontend that I create, and both of these fields are not
intuitive for the 24 hr data set (to the point of appearing broken to 3 of my
end users).

A quick check of the 12 hour format yields similar results. Entering 1222 yields
12:59PM where one might expect it to simply adjust for the colon and make a
guess at the AM/PM.

I think that by improving the intelligence and error checking of this sort
control more users will be inclined to use the system.

berglundma, I well understand that the behavior is as you described. What I'm
trying to say is that neither formatted nor the time field are designed for what
you want them to do. Implementing this particular intelligence, as you call it
(I usually call it "magic" :) ) would be possible, but it wouldn't stop there.
With the same right, one could request that for date formats such as MM/DD/YYYY,
entering the mere numbers without the slashes would be accepted. And here, at
the latest, it becomes difficult, as all the different locales supported by OOo
have different requirements here. Not to mention that people would start wanting
to enter "111209" instead of "11122009". And the next consequence would be that
people want to enter "112009" instead of 201012009". Handling all those cases
properly, and guessing what the user could have meant (and in some cases, it
could be nothing but guessing) would be quite error-prone, and lead to too many
undesired results.

Thus, I continue to claim: The formatted/time field is not designed to what you
required - omit the ":" when entering a time -, the pattern field *is*.

Clearly at this point we are into opinion, but I suggest that because there is a
pattern being specified in the controls format selection, this expectation is
not unresonable. 

As you pointed out, 02/02/2002 could be represented by 02022002 or 020202 except
that there is a difference in the accepted format between the two. There is a
format for 02/02/2002 and 02/02/02, and they are different. In each case an
intelligent decision can be made. It would also be possible for a regional
setting to make sense of reasonable input, respecting the various global
expectations for these sorts of formats. From a programmatic prospective I
understand the need to minimize code and not arbitrarily predict input, but I
also know that we really need to allow for the end user as well, and I'm not
sure that we're doing that.

I agree, this idea doesn't stop with 24 hour times. I'm sure that we can find a
number of other places where input styles (dates) can be improved and made more
intelligent. For the user, sure, it is magic! And (for them) it just works(tm).

Implementing a Pattern field makes sense for something for which we do *not*
have a predefined format. In this case we have pre-defined formatting for many
number styles (currency, times, dates, scientific notation, etc.) and yes, I
suggest that there are regionally understood shorthands for which the computer
can, and should, compensate. 

At the risk of being redundant, I see _not_ doing things like this as making
data entry pedantic for OOo. I think this fundamentally changes the usability of
OOo for end users, especially when compared to other experiences.
 
I very much appreciate your time and our discussion. Your insight has been
valuable to me. I have moved this to enhancement.

Work-around with a pattern field and the right field formatting:
http://user.services.openoffice.org/en/forum/viewtopic.php?f=13&t=22506

See comment 1