Standardize number of digits on date/time fields

[elisekalstad]

Standardize number of digits on date/time fields

[elisekalstad]

This is also an issue as a Program Admin downloading the CSV for applications.

[swatkat1]

@elisekalstad - If it's a CSV issue, can we get a sign off from other entities too?

[nb1701]

Sorry @swatkat1 , didn't notice you had picked this up before I put up a PR. I pinged Isabel and Shreya to make sure this is okay to do for other CEs as well. It will affect CSV, API, and PDF exports, as well as the UI where we show timestamps.

[avaleske]

Confirmed with Matthew at Arkansas that since they're not fully live yet we can switch to an ISO date format without needing to put it behind a feature flag first. Once we know what release it's in we can let them know.

I think the best format to use is the ISO_OFFSET_DATE_TIME from https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html, which looks like 2011-12-03T10:15:30+01:00 but we should confirm that excel and tableau do the right thing and parse it correctly and let you pick the display format that you want.

[nb1701]

@elisekalstad We were thinking for CSV and the API, we could use ISO_OFFSET_DATE_TIME which looks like 2011-12-03T10:15:30+01:00 as mentioned above, but that perhaps is not the most readable thing. For PDF we could maybe do RFC_1123_DATE_TIME which looks like Tue, 3 Jun 2008 11:05:30 GMT. Or we could just always do ISO. What do you think?

Edit: Actually, it seems Excel may not recognize this as a date. Had a discussion in our sync, still not really settled on what we're going to do. We'll jam with @isabelcshaw and figure out what we want to do here. I think probably for the API we should use the ISO format, but CSV/PDF could be whatever.

[swatkat1]

@nb1701 and @avaleske --> Elise is OOO till mid march. I am adding @msprenke for visibility.

[nb1701]

For now, we will move the API output to ISO 8601, and will leave the CSV export as-is expect with a two-digit hour always.