search

msupply-foundation / open-msupply

Open mSupply represents our most recent advancement in the Logistics Management Information System (LMIS), expanding on more than two decades of development inherited from the well-established legacy of the original mSupply.
https://msupply.foundation/open-msupply/
Other
23 stars 15 forks source link

Use client timezone as offset for fridge tag upload #3665

Open andreievg opened 6 months ago

andreievg commented 6 months ago

What went wrong? šŸ˜²

A carry over from issue https://github.com/msupply-foundation/open-msupply/issues/2690 and PR https://github.com/msupply-foundation/open-msupply/pull/3047 There was a fine print in that issue: `I've used something like this but just using server local datetime, but the client may not match the server.`, that might have been missed. In the PR we ended up using server timezone, which is ok for now, but would be problematic if client timezone is different to server. ## Expected behaviour šŸ¤” Timezone form client is used rather then server for fridge tag date time offsets ## How to Reproduce šŸ”Ø I haven't actually tried to reproduce. But the steps should be: Use a cloud server that has different timezone to your machine. Upload fridge tag data from https://github.com/msupply-foundation/temperature-sensor/blob/main/data/FridgeTag%202L/130500109088_202206081014.txt. Inspect data in UI and temperatures / datetimes should match ## Extra Not a very high priority ## Suggested solution Client will need to send it's timezone offset when upload fridge tag data, which is used as the offset in convert_from_localtime ## Your environment šŸŒ±
Chris-Petty commented 6 months ago

@andreievg obvs I'm a bit of an outsider for this, I thought we'd use naivetime? Appears we do looking at the PR so I don't really see how this is different from datetime fields throughout the whole system? If they have a central server in the netherlands but the sync client is in the Pacific then šŸ¤·.

If every store or every site had gps coordinates we could automatically show the right timezone based on that rather than using the OS timezone, I wonder if that idea has any legs.

andreievg commented 6 months ago

how this is different from datetime fields throughout the whole system

When we enter a filter in omSupply, we expect that filter to be in OS timezone, so it is translated to OS timezone (browser would send that datetime filter with timezone offset), and back end would translate it to UTC as naive datetime and use that in the query.

For fridge tag, data in .txt does not have timezone. Fridge tag file is processed on server when downloaded, how do we know which timezone it is in ? We should use timezone of OS which has the fridge tag plugged in, rather than timezone of the server receiving the fridge tag upload, and the one that is processing it.

Chris-Petty commented 6 months ago

Gotcha! Thanks that makes sense