Canadian notation for "Date" field: YYYY-MM-DD

[anikbrazeau]

Issue/opportunity

The current date field format suggests mm/dd/yyyy, which is typically an American notation?

Perhaps we might consider changing it to YYYY-MM-DD to align with the more expected Canadian format that works in French as well?

Screenshots

Related card: https://app.zenhub.com/workspaces/gcforms-60cb8929764d71000e481cab/issues/gh/cds-snc/platform-forms-client/1666

Acceptance Criteria:

• [ ] Update and solidify designs based on testing feedback/findings

[anikbrazeau]

potentially somewhat related to #1712

[srtalbot]

Confirmed that the standard for the GC is YYYY-MM-DD

This also affect our error validation.

[timarney]

@srtalbot can you point me to an existing "live" form / json with a date field --- I'm looking to confirm confirm current production (ideally pre form builder) vs staging.

[srtalbot]

@timarney here's an example with the date validation: https://forms-formulaires.alpha.canada.ca/en/id/167

One thing to consider is how we update the content for live forms (there's often a description with the format that is manually input.)

I thiiink (but would have to check) that all of our forms use the date validation string, so we could make sure they all update.

Would probably also want to reach out to clients that have it because they'd be getting it in a different format.

Seeming like a bigger lift than iniitally thought.

[timarney]

Okay yes --- any existing forms with a date field could have the wrong description if we update our description + field validation. ⚠️ Which would break existing forms ⚠️ .

For reference we're not using a "date" input but in the schema we define date as the validation type

 {
      "id": 1,
      "type": "textField",
      "properties": {
       ...
        "validation": {
          "required": false,
          "type": "date"
        },
        "descriptionEn": "Enter a date like, mm/dd/yyyy",
        "descriptionFr": "Entrez une date comme mm/dd/yyyy",

      }
    }

The input field itself is just a text input

Validation in the code:

[srtalbot]

Right, so I'd have to manually search all the forms and update them to use the existing "date" input, rather than just as a validation type. Could we do that programmatically in a release to migrate that code and then merge in the changes to the format in a later update?

[timarney]

It's a bit tricky and we need to be very careful --- i.e. don't try to do that for this release.

The input remains the same input

1) timing --- We need to push a release to update the date validation

Once that's pushed ... any descriptions that say mm/dd/yyyy will be incorrect

2) Yes we would need to write a migration script looking for fields that have "date" as the validation type and "mm/dd/yyyy" in the description text.

☝️

ping @bryan-robitaille and @craigzour --- has anything like this been done before on this project ?

[bryan-robitaille]

No, nothing of that magnitude where we're scanning existing forms for a specific form field/description and then swapping out the block. I agree the lift is going to be bigger than initially thought if we have to take all existing old forms into account.

[srtalbot]

Moved to product backlog given the lift.

If we're looking at error messages and writing migration scripts, let's see if there's anything in the Error messaging and Pages epic.

[connorscarolyns]

Is there an option for users to choose which format they want to request? dd-mm-yyyy mm-dd-yyyy or yyyy-mm-dd ? Guidance from the UK is that dates should be requested in the format that dates are printed on source documents. Like the date printed on their renewal form or whatever. In this case, there is a need to have different options. Also would allow us to be backward compatible.

[anikbrazeau]

Maybe we could have the default be one of the more bilingual-friendly formats: yyyy-mm-dd?

Curious, whether there have also been other explorations done to break up this field into multiple? ex: Day [] Month [____] Year []

[connorscarolyns]

I have recommended the three-field approach and would like to see it implemented, but the order of the fields still needs to be addressed. Taking our cues from the UKDS they suggest ordering the dates in the order they appear on the source material, not by any formal standard format. This reduces entry errors. That said, the default should be as inclusive as possible.

[connorscarolyns]

Concept designs for date entry options: https://www.figma.com/file/89fRce4gmy64UIArSZoAM8/v3.-GC-Forms-(builder-and-vault)?type=design&node-id=1507%3A52213&t=UPzEeErNjTgDJIgO-1

[connorscarolyns]

New design proposal for dates: https://www.figma.com/file/gkmd5aQpcnjuPeAT51oIFs/v2.-Add-modal?type=design&node-id=2241-3599&mode=design&t=W5zabKMhl3wg910R-4

[anikbrazeau]

Design system component for dates: https://www.figma.com/file/mh2maMG2NBtk41k1O1UGHV/branch/zbR8hajann6ga4AHWPOWcm/Canadian-Digital-Service%E2%80%A8---GC-Design-System?type=design&node-id=14220-878&mode=design&t=dKx2jbPugc4knxC3-0

[srtalbot]

Feedback from end-users filling out the date field at a live event providing consent to use their likeness in press releases:

• People would often fail two or three times to fill out the date field correctly (with "Today's" date)
• The / was a particular annoyance
• The date format dd/mm/yyyy was also difficult
• The client theorized that separate boxes would also help.

Perhaps we could scope down the designs above to get a smaller version of the feature out sooner? What do you think @dsamojlenko @connorscarolyns ?

[connorscarolyns]

@srtalbot @dsamojlenko I will happily pair this down as much as needed to see this ticket move forward. It was scoped at a point when we thought we had more time. Dave, let's meet and see what's the best way to cut this back. SR - how many story-points can we get to complete it?