Support entry format for date and time in questionnaire.

[PallaviGanorkar]

Describe the bug
Developer should define the date format for the questionnaire.
More details are available in #1802 as this issue is one part of issue #1802

Component
SDC library

[PallaviGanorkar]

Summary of last discussion on Time input widget in DateTime Component ,

1. Time input component will allow to second as well like hh:mm:ss
2. Allow free text input for Time input component as well in both scenario like format is given in questionnaire or its device local format
3. In free text input , separator will be added automatically like date input
4. CanonicalizedTimeFormat to 2 digit for h, m and s

[PallaviGanorkar]

@jingtang10 @shelaghm , I have some finding on Time input widget in DateTime Component

1. Out of below 4 format styles for time, SDC can support FormatStyle.SHORT and FormatStyle.MEDIUM

• FormatStyle.SHORT- "h:mm a"
• FormatStyle.MEDIUM- "h:mm:ss a"
• FormatStyle.LONG- "h:mm:ss a z"
• FormatStyle.FULL- "h:mm:ss a zzzz"
  As other 2 LONG and full includes time zone 'z' factor use alphabets which are difficult for the user to input
  e.g.
  locale : ko_KR FormatStyle.LONG- "a h시 m분 s초 z"
  locale : ko_KR FormatStyle.FULL- "a h시 m분 s초 zzzz"
  locale : ja_JP FormatStyle.LONG localeFormat- "H時mm分ss秒 zzzz" canonicalizedFormat- "HH時mm分ss秒 zzzz"

2. There is observation with FormatStyle.MEDIUM, In MaterialTimePicker, Hour and minutes are allowed but don't have method to set seconds.

3. From https://developer.android.com/reference/android/icu/text/SimpleDateFormat
   For 'a' (period) AM or PM format is only supported So SDC will have this support only and for other pattern like a.m. or p.m. , will show format error

4. Currently "H" is supported for 24 hours TimeFormat and "h" is supported for 12 hours TimeFormat , but above link in point 3 ICU supports "k" (for 24 hours) and "K" (for 12 hours ), Shall we support this as well?

5. Also for seconds it has "s" for 2 digits and "S" for n digits, Here currently supported 's' for 2digits, let me now if have other thoughts

6. For free text input

• if android:inputType="time" is used it won't allow to enter " " space before "a" from keyboard nor auto append also no alphabet on keyboard to enter "AM/PM"
• if android:inputType="datetime" is used, it allows to to enter space but no alphabet on keyboard to enter "AM/PM"
• if android:inputType="text" is used, then it works but keys are very small as discussed in case of date input widget.
• In MaterialTimePicker with INPUT_MODE_KEYBOARD ,ther is no alphabet on keyboard to enter "AM/PM" it has UI to select AM/PM

[shelaghm]

@PallaviGanorkar Thanks, some thoughts below

(1) and (2) and (5) Is there a use case where people need to enter seconds? I don't know of a use case where someone needs to enter seconds, it's too much precision. Having seconds seems to add a lot of additional complexity without adding value. I suggest we use FormatStyle.SHORT- "h:mm a"

(3) I think we should use the time picker input field that comes with the AM/PM selection so people are not manually adding their own AM/PM text. See material.io for picker dial and for time picker input. Github link for implementation info

(4) I don't understand the difference between h, H and k, K enough to provide guidance on if we should support both. @jingtang10 maybe you can add your thoughts?

(6) What is your question here? Is it to pick one? MaterialTimePicker with INPUT_MODE_KEYBOARD sounds like the best direction, as we want users to select the AM/PM with the UI not the keyboard

[PallaviGanorkar]

@shelaghm

(3) As per this point , do you mean instead of allowing free text input in TextView, SDC must show UI as per time picker input for text entry?

(6) I have listed some implementation issue for time picker free text entry for time.
But as per you 3rd point if we use INPUT_MODE_KEYBOARD for text entry then this issues no more exists

@jingtang10 looking forward for you opinion as well on above points

[shelaghm]

(3) Yes, that's right. Use the material UI for time picker input, not a textfield box.

[jingtang10]

i'm concerned about the difference in how we handle date and time input - i think we should try to provide a consistent experience if possible.

[shelaghm]

Okay, I have three options I can think of.

1. Make dateTime consistent with date and add a dropdown selection for AM/PM if it is not 24h time.
2. Ignore consistency and follow GM3 patterns for time Input with default to the Time keyboard entry. If click the time icon, then the TimePicker shows up.
3. Change Date picker to use the GM3 modal for date entry. We didn't do this for a reason before, probably because of entry format?

My preference is option 2, as I'm not too concerned about consistency as I think it's a better experience to enter time. I'm also okay with option 1. What do you think @PallaviGanorkar @jingtang10?

Mocks below.

[shelaghm]

@rowo @HenryRae @joiskash We'd like to hear your input on how you're planning to use DateTime or Time entry.

1. What scenarios would you use DateTime entry for?
2. What level of precision are you doing Time entry in? (hours, minutes, seconds, etc)
3. Time format: AM/PM or 24h clock?

We want to make sure we are considering the right requirements while making decision on this issue. Thank you for your input.

[joiskash]

1. We will mainly use DateTime entry for observations that are extracted from the answer of the questionnaire response. The tricky part with this is that a question that asks for last menstrual period would typically be answered with only a date, but if you want to save this as an observation, you need to use DateTime since observations do not have valueDate.
2. Time entry precision that we expect is around 30 min. eg: for appointment scheduling. People wont schedule appointments for 9:17 am. It will either be 9:00 am or 9:30 am.
3. AM / PM is preferred. The feedback we received from the ground is that people are not aware of 24 hour clock formats.

[PallaviGanorkar]

@jingtang10 FYI,
Supported entry format in questionnaire for date component, PR IS raised and all review comments are addressed in this PR except selLocale() in Espresso Test in QuestionnaireUiEspressoTest class

[HenryRae]

@rowo @HenryRae @joiskash We'd like to hear your input on how you're planning to use DateTime or Time entry.

1. What scenarios would you use DateTime entry for?
2. What level of precision are you doing Time entry in? (hours, minutes, seconds, etc)
3. Time format: AM/PM or 24h clock?

We want to make sure we are considering the right requirements while making decision on this issue. Thank you for your input.

@shelaghm currently I don't think we have a scenario for time entry(I stand to be corrected @rowo) but the most common formats I've seen in East Africa are 12hrs format(Am/PM) and simple precision i.e hours and minutes
However my suggestion could be we make time format configurable, some Western and South African countries might be using 24hrs clock.

[HenryRae]

The issue I raised here on the date picker might be more appropriate to raise here.

Can we make the date picker configurable, this(see screenshot) type of date picker is found to be easy to use than the one used in the designs.

[shelaghm]

@HenryRae We have this alternative date picker in a separate issue #1805 It's quite unfortunate that material design has implemented a date picker that doesn't work well for entering dates. I'll add your comment in that issue so we can track demand and maybe we can find an engineer that has bandwidth to build this component.

[shelaghm]

@HenryRae @joiskash Thanks for your input on time scenarios and level of precision needed. Very helpful.

Conclusions:

• Not many use cases for TimeDate at the moment, except for scheduling an appointment and the need to extract TimeDate from an Observation
• Support both AM/PM and 24h clock
• Support hour/minute precision level (not seconds)