Timeline for Is timestamptz preferred when timezone logic is performed by the client?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 25, 2018 at 17:33 | history | rollback | Evan Carroll |
Rollback to Revision 2
|
|
| Apr 25, 2018 at 13:00 | history | edited | Evan Carroll | CC BY-SA 3.0 |
added 2 characters in body
|
| Apr 24, 2018 at 0:02 | comment | added | Evan Carroll | Because like language itself, people won't speak "just Latin" for ever. And it's better to write code that doesn't make assumptions about the client. I would rather not have implicit assumptions if not needed at all. | |
| Apr 23, 2018 at 21:28 | comment | added | berkeleybross | I guess I'm just not seeing the advantage of timestamptz if all clients expect UTC. To me it's a little like saying you should use a mythical type which stores all text in French, but translates it to and from the current users language (perfectly) on input/output. This type has more features, but the end result is the same if all clients are English - so why use the more complicated type? Am I just blinded by being in the UK and UTC is usually the right time for me? Would I have a different opinion if I was in a different timezone? | |
| Apr 22, 2018 at 5:03 | history | edited | Evan Carroll | CC BY-SA 3.0 |
added 43 characters in body
|
| Apr 22, 2018 at 4:56 | history | answered | Evan Carroll | CC BY-SA 3.0 |