A couple changes: moving forward, rather than using the dateTimeOriginal field from images, we'll use dateTimeUTC, which is adjusted for the timezone in which the deployment lives and shifted to UTC+0. We should assume that ALL dates (deployment start/end dates, dates in filters, etc.) will be sent as and evaluated in UTC+0 from the back end. I'm also thinking of moving to using ISO 8601 for all external dates so we may need to update parsing on the front end.
TODO's on the frontend include:
[x] include timezone selector on create deployment form
[x] pull dateTimeUTC field from images
[x] shift dateTimeUTC field to user's local timezone and use through out
[x] any time users are sending dates to the back end (e.g. when creating date filters or creating deployments), treat the dates in the UI like they're in their computer's local timezone, but convert to UTC+0 before posting to backend
[ ] also consider offering a TZ selection to the date filters so that if the user is in Germany but wants to look at CA images that were taken between two dates, they can make the query in the same timezone as the cameras
[x] use Luxon instead of Moment
[x] if we shift to sending ISO 8601 dates to the front end, update parsing
See https://github.com/tnc-ca-geo/animl-api/issues/35 for corresponding issue in
animl-api
.A couple changes: moving forward, rather than using the
dateTimeOriginal
field from images, we'll usedateTimeUTC
, which is adjusted for the timezone in which the deployment lives and shifted to UTC+0. We should assume that ALL dates (deployment start/end dates, dates in filters, etc.) will be sent as and evaluated in UTC+0 from the back end. I'm also thinking of moving to using ISO 8601 for all external dates so we may need to update parsing on the front end.TODO's on the frontend include:
dateTimeUTC
field from imagesdateTimeUTC
field to user's local timezone and use through out