joeinnes
commented
2 years ago Now I am hardcoding a 2hr offset. Will need to actually get data from the user. Key Paths are updated
Open joeinnes opened 2 years ago
joeinnes
commented
2 years ago Now I am hardcoding a 2hr offset. Will need to actually get data from the user. Key Paths are updated
EXIF data does not allow definitive determination of a timestamp, as data is stored without timezone information. Incidentally, it's also in a weird format (1970:01:01 01:01:01) which is based on ISO 8601 but for some reason not quite conformant to the standard.
Currently when uploaded, the server parses the EXIF tag and sets this as part of the key (yes, I'm fully aware of the irony of complaining about the exif implementation when I'm implementing key paths which are YYYY-MM/DD-HH-MM-SS-XXX).
I'd like to allow the user to select a UTC offset timezone when uploading. This would then be used to convert the EXIF data to UTC. Should be easy enough to calculate the users current UTC offset (famous last words). The good news is that no-one is going to die because their photos' timestamps are off, so I can make some broad, sweeping design choices which may be 'good enough'.
Interesting question: does anyone care about the timezone the VIEWER is in? My gut tells me no, so that means I will need to also store a UTC offset in the key, and interpret that client-side.
Then there could be a frontend control to switch between viewing in original timezone (e.g., if the photo was taken at 6pm in Budapest, it will show as 6pm even if accessed from London), viewing in the browser's current timezone (e.g., if the photo was taken at 6pm in Budapest, it will show as 5pm when accessed from London), or with any other arbitrary offset.
So, plan:
[] S3 Key will become YYYY/MM/DD/HH:MM:SS±hh:mm-XXXX, where XXXX is the filename. (e.g., 1970/01/01/01:01:01+00:00-IMG_12345.jpg) [] FileUpload component will feature a dropdown allowing users to select timezone and a specific UTC offset (potentially in an 'advanced' collapsible section?). This should be pre-populated with the browser's current UTC offset and location (
console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)) [] Front end should be refactored to parse and interpret the UTC timestamp in either a) original format (default), b) browser's current offset, or c) some other arbitrary UTC offset. This is probably a configuration choice, so should not live prominently in the display. date-fns-tz hasformatInTimeZoneandutcToZonedTimewhich might help here.