fixes CNVS-4963
canvas stores and treats these values as datetimes internally.
additionally, some customers depend on the datetime functionality, so
it's not just a matter of disconnect between representation and
semantics.
not only does displaying them as dates instead of datetimes hide
information that some customers may depend on, but it also risks losing
that information entirely when the form is loaded and then saved (even
if that field was not explicitly modified).
it gets even worse when userA saves the end date to an implicit midnight
in one time zone, and then userB round trips the form in another time
zone, causing the date to shift by whole days unintentionally.
treating it as a datetime in the input rather than as a date fixes all
of these.
test-plan:
- create a course with a teacher
- set the teacher's time zone to Baghdad (+03:00)
- as the course teacher, set the course start_at to 6am on some day
- load the course settings page and click "Edit Course Details"; the
time portion of the start date should be displayed in the input
- click the datepicker for the start date; the time portion should be
displayed and filled
- save the form; the start at should not change
- change the teacher's time zone to Alaska (-09:00)
- reload the course settings page and click "Edit Course Details"; the
input should read as 6pm on the previous day
- save the form; the start at should not change
- change the teacher's time zone back to Baghdad
- reload the course settings page; the course start at should be 6am on
the originally selected date
- repeat the above for course end date
Change-Id: I97c78ea2861e9d792d4f0d9d3fb121f5a83ab38b
Reviewed-on: https://gerrit.instructure.com/22206
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Matt Goodwin <mattg@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
65b1e19244
