3 ms·
But you are tying it to a timezone: the timezone that will be valid at the place and date that the meeting is at. Basically, a timestamp should be tied to a ti
by perlgeek 8y ago
But you are tying it to a timezone: the timezone that will be valid at the place and date that the meeting is at.
Basically, a timestamp should be tied to a timezone or a location, or at worst an indirection (like you being at a specific location). And since we don't tend to have practical support for tying timestamps to locations, we tie them to timezones instead.
- fphilipe 8y agoI've written a post about timestamp vs timestamptz and the only valid reason for timestamp I could come up with is exactly this, scheduling events in the future: https://phili.pe/posts/timestamps-and-time-zones-in-postgresql/#a-valid-use-case-for-timestamp-without-time-zone https://phili.pe/posts/timestamps-and-time-zones-in-postgres...
- stickfigure 8y agoI have implemented an event ticketing system. One of the things I (fortunately) realized early was that storing times with timezones would be a problem: Events get moved, occasionally across timezone boundaries. If you store epoch-instants, then the logic for "set location" would also have to update every timetsamp in the database associated with the event. IMO, in a database you should store the "natural" representation of date-time as your users think of it. Sometimes (like your alarm clock), it's timezone-less concept. Sometimes (like a sporting event) it's a combination of datetime + location. Sometimes (like historical events) that's a fixed instant in time. Recognize which is which and model appropriately.