2 ms·
When I start at a new company, it's always interesting to see how they handle dates and times. 1) Company A stores timestamps in a mysql database, no timezone,
by icedchai 4y ago
When I start at a new company, it's always interesting to see how they handle dates and times. 1) Company A stores timestamps in a mysql database, no timezone, but implicitly on US pacific time. The system timezones are all on pacific. Many weird bugs around DST transitions. 2) Company B stores timestamps in a database as Unix timestamps (ints) Tons of code converting back and forth between ints. Code was a mess. 3) Company C stores them as postgres timestamp with timezone, which was always UTC in production. Code was reasonably sane.
- fingerlocks 4y ago> Tons of code converting back and forth between ints. Code was a mess. Never experienced this myself, it’s trivial in all the languages I can think of. Sometimes you have multiply or divide by 1000 if JavaScript is involved. I always prefer Unix epoch time. What was the language and stack causing the mess so I know to avoid it?
- icedchai 4y agoThe code was a mess for other reasons beyond the int/timestamp conversions. In some places it was stored as milliseconds, other places seconds. It was python 2 if it matters.