DateFormatter Download File Update

Owned by Patricia Donohue
Jan 09, 2019
2 min read

Problem

Solution

The solution to this issue is for the college to change where their format file currently says:

           <field name="birthdate" />

to say:

           <field name="birthdate">
               <dateFormatter pattern="EEE MMM dd hh:mm:ss z YYYY"/>
           </field>
  • Without the dateFormatter element, the download client will use the user's computer's timezone and output pattern (EEE MMM dd hh:mm:ss z YYYY).
  • The dateFormatter element defaults to the UTC timezone and the pattern YYYY-MM-dd.
  • The line <dateFormatter pattern="EEE MMM dd hh:mm:ss z YYYY"/> should use the standard UTC timezone and the output pattern that the college is used to having their data in.

The birthdays in question for this ticket (August 11, 1989 and January 24, 1995) are one day different in some timezones, such as Hawaii.


NOTE:  Per Josh's suggestion, we are not going to make any changes to the download client, lest we break backwards compatibility with expected date outputs. Instead, the college will be able to solve this issue on their end with the instructions provided in the last comment. The data dictionary should probably be updated with this information if it's not already there.



Let's confirm how this - and other existing / future work-arounds - are documented and communicated to the field. I'd like to capture this process as an item that is shared with both Infiniti and ES.
I suggest the following (let me know what you think):
1) Work-arounds are written up individually in Confluence - (OA internal space and/or CCCApply Public Info external space) using the "Troubleshooting" page template
2) at the bottom of that template - we list all required documentation instances and add hyperlinks. Example:
If the issue and work-around pertains to Downloads, the child/dependent documentation links would include:
A) Update (add section or notation) in the Download Client User Guide
B) Update the CCCApply Data Dictionary (if needed)
C) Update the CCCApply Production Support Plan (running/living document - I have the link)
D) Update the CCCApply Support Site (this should really be "A")
E) If warranted - a Special implementation page - which is a section in the CCCApply Public Docs space
Can we think of any others?
don't worry - I'm not suggesting that you guys have to do all this documentation work, BTW - but we may have to share the load since we don't have Diana's time very often.

F) Update the Enabling Services team on the change or new implementation (ES Transition Plan, maybe) but somehow they need to be updated
G) Update Glue team (possibly - depending)
I will schedule a meeting to discuss this - @rfuentes for later this week. Any preference on date/time?