←back to thread

189 points GordonS | 1 comments | | HN request time: 0.209s | source
Show context
robbiep ◴[] No.19533377[source]
I have a question, that was partially addressed in some comments in the last Timezone in Databases article earlier in the week -

What do people think about using Unix time in databases?

replies(4): >>19533555 #>>19533627 #>>19533651 #>>19535478 #
1. niftich ◴[] No.19533651[source]
I feel that storing unix epoch seconds in a >=4-byte fixed length numeric or arbitrary precision numeric column is a reasonable choice if:

1) the record naturally has the semantics of a timestamp that is chiefly used for comparisons between values (e.g. to sort, min, max, subtract to get an approximate interval) and whose conversions to human-meaningful calendrical datetime are not needed or only need to be approximate (given unix timestamps' lack of leap seconds),

AND 2) you've thought about overflow (of both unix time and your column), signed-ness, sentinel and special values, and NULL handling,

AND 3) you're not enthused by the ANSI SQL definitions of TIMESTAMP types or think you, your RDBMS, your database driver, your programming language, your datetime library, or the code's next maintainer might screw something up.

If only the first factor isn't true, use an RFC 3339 UTC timestamp in a string column instead. If only the second factor isn't true, use one of the SQL TIMESTAMP types instead, so you can pick up a better-defined suite of behaviors.