New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MyLA importing incorrect timezone times #1484
Comments
This is incorrect. On 2021-10-17, Here are the updated query options to resolve this: SELECT
posted_at,
posted_at AT TIME ZONE 'America/Detroit' AS "posted_at (original)", -- incorrect
posted_at AT TIME ZONE 'UTC' AS "posted_at (UTC)", -- shows time is unaffected by converting into UTC
posted_at AT TIME ZONE 'UTC' AT TIME ZONE 'America/Detroit' AS "posted_at (America/Detroit)", -- correct time
posted_at::timestamp WITH TIME ZONE AT TIME ZONE 'America/Detroit' AS "posted_at (option 2)", -- correct time
posted_at::timestamptz AT TIME ZONE 'America/Detroit' AS "posted_at (option 3)" -- correct time
FROM entity.learner_activity_result
WHERE learner_activity_result_id = 333333333; credit to @dcgleim for figuring this part out |
Thanks for the report! I've typically preferred to use a specific region like |
@jonespm I put the info about our configuration in the other issue (here). We would prefer to set the institutions' timezones for their MyLA install so that there are not discrepancies like the midnight scenario you described. I foresee that being a feature request/support issue from them down the line if we only use one standard North American timezone. Best option would probably be to only store the datetime as UTC and translate it to the viewer's local time on the frontend or at request time, but that solution is beyond me. We are 100% good with it just being configurable for each instance of MyLA. |
Thanks, I forget why we were doing the conversion it in the cron rather than pulling down "as-is". This looks like it's been in the code since the beginning and I agree probably should be as you describe. Maybe that's something whoever fixes these two issues to look at. I'd expect these will both be in the next release. |
I'm looking at converting to just saving the UTC time locally and doing the conversion there, trying to see if there was some reason we were doing it in the query. This might have to be a separate fix as it's going to be more work changing the migrations, the API's and the frontend. For the immediate fix if we keep it in the query, It looks like we might have to use the timezone function, which supports SQLAlchemy parameter replacement. This returns the same results as your other examples.
|
Also Fixes tl-its-umich-edu#1432 - May need to make America/Detroit in cron config configurable
I changed the TZ value in Test passes |
Expected behavior (A description of what you expected to happen) :
Timestamps for locally computed times, such as the
grade_posted_local_date
field in thesubmission
table, to have the correctly computed time for theAmerica/Detroit
configured timezone.Describe the bug (Tell us what happens instead of the expected behavior) :
Timestamps are showing as 4 hours ahead of UTC instead of 5 hours behind for the correct
America/Detroit
(EST
) time.Steps to Reproduce :
420000002222222
2222222
(dropping the42000000
prefix)420000011111111
learner_activity_result_id
for the assignment:posted_at
field (in the way that it is queried here by MyLA):grade_posted_local_date
in the MyLA query):The
context_store
's timestamps are in UTC.show timezone; TimeZone ---------- UTC
The
America/Detroit
(orEST
) timezone is 5 hours behind UTC, not the 4 hours head that is returned by the queries:grade_posted_local_date
should return2021-10-17 11:49:11.908+00
.America/Detroit
) the incorrect time was still being computed. It was returning a time of only 4 hours behind instead of the correct 5 hours behind.The following contains multiple ways the queries can be corrected to return to correct timestamp:
Additional context (Add any other context about the problem here) :
Affected queries:
The text was updated successfully, but these errors were encountered: