OMG, I’m dealing with a developer right now that is dealing with patient collected samples in several timezones, allowing the patients to either enter the time they collected, or use current time, and storing it in UTC time.
We do not receive any timezone data, patient collection data is showing different days than the patient could write on their samples depending on the time of day, and the developer said ‘just subtract X hours’ (our timezone)… for which not all patients would live in.
I suppose I could, if they’d provide the patient’s timezone, but they don’t even collect that. Can you just admit your solution is bad? It’s fine to store a timestamp in UTC, but not user provided data… don’t expect average users to calculate their time (and date) in UTC please.
Depends on what’s collecting the information. If it’s a website, then the client-side code could most certainly normalize everything to UTC based on the browsers time zone before submitting. That’s what I would probably do, if the user’s time zone isn’t needed or wanted…
Obviously they are getting timezone information otherwise the app could only display whatever time the user entered in.
If you want to sort things by the actual time, it’s simple and performant if all of the times are in the same timezone, and UTC would be the standard one to use. Pushing the timezone calculations to the client makes sense because the UTC time is correct, it’s just a matter of displaying it in a user friendly way, ie. show the time in the user’s timezone.
OMG, I’m dealing with a developer right now that is dealing with patient collected samples in several timezones, allowing the patients to either enter the time they collected, or use current time, and storing it in UTC time.
We do not receive any timezone data, patient collection data is showing different days than the patient could write on their samples depending on the time of day, and the developer said ‘just subtract X hours’ (our timezone)… for which not all patients would live in.
I suppose I could, if they’d provide the patient’s timezone, but they don’t even collect that. Can you just admit your solution is bad? It’s fine to store a timestamp in UTC, but not user provided data… don’t expect average users to calculate their time (and date) in UTC please.
Depends on what’s collecting the information. If it’s a website, then the client-side code could most certainly normalize everything to UTC based on the browsers time zone before submitting. That’s what I would probably do, if the user’s time zone isn’t needed or wanted…
This is actually the best approach.
Obviously they are getting timezone information otherwise the app could only display whatever time the user entered in.
If you want to sort things by the actual time, it’s simple and performant if all of the times are in the same timezone, and UTC would be the standard one to use. Pushing the timezone calculations to the client makes sense because the UTC time is correct, it’s just a matter of displaying it in a user friendly way, ie. show the time in the user’s timezone.