Issue 104504 - TimeField/FormattedField badly handle 24 hour time
Summary: TimeField/FormattedField badly handle 24 hour time
Status: UNCONFIRMED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOO310m11
Hardware: PC Windows XP
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-25 20:25 UTC by berglundma
Modified: 2013-02-07 22:39 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description berglundma 2009-08-25 20:25:59 UTC
When using a timefield or formattedfield (formatted to deal with 24 hour time)
it seems that the field does not handle input well. You *must* enter the data
with a colon. If you enter a number like 2345, while this may be a valid time,
it is rounded to 00:00. Additionally if you enter any number below 2147 you are
returned 23:59. It seems that once you go over 2148 (inclusive) the algorithm
rolls over to 00:00. We are currently writing macros to get around this for
non-programming types.

My (and my coworkers) expectations are that if a 4 digit number is entered, it
is treated as a evaluate as a time (0000 to 2359). It seems pedantic to require
the user to enter the colon (or formatting symbols which can be assumed) so long
as the number is a properly formatted integer for the type.

I will be checking this on other systems as I can.
Comment 1 Frank Schönheit 2009-08-25 21:39:03 UTC
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.
Comment 2 berglundma 2009-08-26 07:27:41 UTC
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.
Comment 3 Frank Schönheit 2009-08-26 08:03:38 UTC
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*.
Comment 4 berglundma 2009-08-26 14:02:52 UTC
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.
Comment 5 villeroy 2010-01-17 07:56:21 UTC
Work-around with a pattern field and the right field formatting:
http://user.services.openoffice.org/en/forum/viewtopic.php?f=13&t=22506