Date-time Input (UI) Requirements

Owned by Rick Jaffe
Last updated: Aug 14, 2020
3 min read

Functional Specifications

Time

  • Compatible with React 15

  • Default time: 12:00 AM

  • Granularity: Seconds

  • Time entry: 12-hour plus AM/PM field. Time picker does not affect the date (i.e., increasing or decreasing the time past 12 midnight does not change the date value).

  • Times may be entered by typing numerical values or via up- and down-arrows or some other graphical means.

  • Time zone default: local time. Time zone selection dropdown/widget is included.

  • Time zone behavior should align with the way that the current date input behaves with respect to time zone. The current date picker is free of time zones, i.e., “CSpace strips away time information. Uses method to prevent conversion to local time.”

  • Natural language parsing, e.g., “Half hour from now”; “Quarter after 5” = 5:15. Nice to have, but not required (not in v1, at least). Ray adds: “you'll find that the library that is used to parse the natural language dates already supports a bunch of stuff. Just use that. See https://sugarjs.com/dates/”

  • Time range: “User can manually add a time or range of times to an object, procedural, or organizational record” and “User can choose a time or span of time from a time picker to add to an object, procedural, or organizational record” (See Date and Time User Story Summary document; emphasis added.) Nice to have, but not required (not in v1, at least).

Date

  • Calendar dates may be entered using the provided date picker or via the text-entry field.

  • Dates may be entered in a variety of formats, including YYYY-MM-DD and MM/DD/YYYY.

  • Leading zeros are not required.

  • Users may enter "yesterday", "tomorrow", "next tuesday," etc., exactly as in the date picker

  • In the default CollectionSpace configuration, dates entered in formats other than YYYY-MM-DD will be returned in that format after pressing enter. You may configure an alternative default date format for your organization.

Background

The UI widget in the the locationDate field on the movement (LMI) record – the field used to compute an object’s current location – is currently a date picker, even though the underlying field in the data schema is a datetime field. When implementing CollectionSpace at UC Berkeley, developers created a tie-breaker algorithm to determine the order of two or more records created on the same day. Tie-breaker issues have been wreaking havoc with Tricoder-assisted moves at UC Berkeley museums. Objects may be moved multiple times per day (for example, moved from one location and to a new location). The resulting Tricoder records, which are uploaded after the fact, can be submitted in a different order than they are recorded. As a result, current locations are sometimes being determined by a move other than the final one. CollectionSpace deployers cannot move away from the tie-breaker, however, unless users who manually enter Move dates can enter a time value. Hence the need for a date-time input widget: to minimize reliance on the tie-breaker functionality and instead base the order of the moves on the time recorded (or entered) at the moment the move is made.

Q: What other fields need a time picker? 

  • Use of Collections - Date requested: “having a datetime picker for Date Requested would be helpful for those cases where researchers submit multiple research requests on the same day. I'd classify it as nice to have, but not necessary.” - Michael Black, Hearst Museum, UC Berkeley

  • No others

  • We do not need to be comprehensive. We can roll out other fields later.

Assumptions

  1. Issues with the Location Movement tie-breaker are causing errors in current location values. Implementing a datetime UI input will address those issues.

  2. The datetime input will not replace the current date picker. Rather, it will be available for use on fields for which it is better-suited.

  3. The datetime input must work very similarly to the date input. Basically, the same, but with time. Otherwise it will be confusing for end users. This includes allowing users to type "yesterday", "tomorrow", "next tuesday," etc., but with times.

  4. The datetime input will be compatible with REACT 15

  5. The datetime input will accept the libraries that are used with the date input to enable natural language parsing, etc.

  6. Developer (i.e., Ray) can change the styling of the clock

    1. Bring in Flint for design/UX assistance?

  7. This does not affect the structured date fields.