On Tue, Aug 13, 2019 at 7:30 PM J Decker <d3c...@gmail.com> wrote: > > > Why are you storing the timezone? You display the TZ of the user who is, > > later, viewing the data. And that user could be anywhere. > > Because the actual time on the clock on the wall matters. > I want to know cashiers that are making transactions outside of 9am-5pm > (for instance). But depending on where they are that time is different. > I also want to know the time continuously according to the linear time that > they happened in. > > The time on the clock is irrelevant, completely and totally, due to daylight saving. Moving the clock back and forth twice a year causes a chunk of time to go missing or a chunk of time to be duplicated. The clock is a User Interface problem, not a data storage problem. When you want to know that locations actual time, you store that stores location with their TZ information, and your UI presents that information to you.
Because UTC does not move forward or backwards (Occasionally we add a second due to the rotation of the earth slowing down*, but we NEVER go backwards), anything time related in a database NEEDS to be stored in UTC/Zulu/GMT-0 time (Or whatever you want to call it). This is THE base time. Sure, you COULD store the location, but, if you're in British Columbia, looking at a stores transactions in New Found Land, (Or say California versus New York), what time do you believe? I work for a company that literally has servers all around the world, which means Time Zones ARE a thing for us. We set every single machine we deploy to UTC. If there were any times to be displayed in "local" time, it's handled at the application/presentation layer, not the database layer. *https://www.quora.com/Why-is-Earths-rotation-slowing-down -- First hit on Google. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
