KTimeChooser moved to kdereview

[Michael Leupold]

David Jarvie schrieb:
> On Tue, August 25, 2009 1:08 pm, Michael Leupold wrote:
>> I just moved a new widget for editing times to kdereview: KTimeChooser.
>>
>> It is a reworked version of KPIM::KTimeEdit, basically a time editing
>> widget
>> with a combobox containing a list of predefined times (with configurable
>> interval between them). It is meant to be used in places where the user is
>> more likely to choose a time using the combobox than entering it manually
>> (eg. when scheduling meetings which usually begin at :00, :15, :30 or
>> :45).
>>
>> Other features:
>> - Times can be entered and displayed using the configured time format
>> - Additionally times can be entered in military (eg. 1830) or plain 24h
>> format (eg. 18:30). Those times will be recognized and "localized" using
>> KTimeValidator (private API).
> 
> Is it sensible to allow military or 24 hour time entry when the localised
> time format is the 12 hour clock? This could lead to ambiguity and errors.
> For example, if the locale is set to the 12 hour clock and the user enters
> a military time of 1245, or 24 hour time of 12:45, how does the widget
> know whether that should be interpreted as 12:45 in the afternoon
> (assuming a military/24 hour time), or 12:45 in the morning (12.45 am ==
> 00:45) (assuming a 12 hour clock)?
> 
> There could be a rule that a lack of punctuation (entering "1245")
> indicates military time, but the user might not be aware of this rule,
> which would lead to occasional errors.

Basically it just tries locale defined, then 24h, then military one 
after the other until it succeeds. Generally only the latter doesn't 
require punctuation so 1245 will always be parsed as military and 
resolve to "12:45 pm".

The problem with the 12h formats is that there's no way to resolve the 
ambiguity automatically. But I guess the only range where that really 
matters is 12:01 - 12:59 as those are the only times where the localized 
text without the am/pm suffix matches for am and pm (or rather: I don't 
think a user would expect 08:45 or 0845 to resolve to 08:45 pm instead 
of am).

Alternatives:
- Current implementation: 1/12 of times may lead to wrong assumptions 
about what the user wants. This can lead to accidental errors.
- Don't parse 24h/military: No accidental errors (form can block 
submission due to invalid input) but user will have to reedit more often 
if he makes a mistake.
- Parse 24h/military times but map 12:01-12:59 to am instead of pm: 1/12 
of times may lead to wrong assumptions (same as current but makes other 
assumption about what the user expects)

I prefer the current implementation. KPIM::KTimeEdit already displays 
localized format and also accepts military time (though no 24h format). 
But I'm not using 12h format so I don't know if the 12:01-12:59 => am 
mapping does feel strange.

Regards,
Michael