
64-bit unix timestamp is not supported in MySQL functions (2005) - tobyjsullivan
https://bugs.mysql.com/bug.php?id=12654
======
PeterZaitsev
Note - MySQL Have 2 data types. One is TIMESTAMP which is signed 32bit
timestamp which is very useful for times around now. There is also DATETIME
type which has broad range and this is what you should use in general

~~~
q3k
MySQL has more unfortunately-named time-related types than Python, which IMO
is quite the achievement:

    
    
       - TIME
       - DATE
       - YEAR
       - TIMESTAMP
       - DATETIME

~~~
PhasmaFelis
Whoever set up the database for my current work project apparently thought
that wasn't enough, because it's got a whole lot of columns called
"dateTimeStamp" which--on inspection--turn out to be VARCHARs containing a
string representation of a timestamp. In ISO 8601 format. The one that looks
like "2019-12-11T00:04:37.754329Z".

Yes, they actually have six decimal digits of precision. For tracking boxes on
a warehouse conveyor belt.

~~~
blattimwind
First time I've seen someone complain about finding standard ISO 8601 in a
database.

~~~
PhasmaFelis
This particular database is mainly used to display results to humans, and
whoever wrote the original code didn't bother to convert it from 8601 to
human-readable (one of the things I'm fixing), so it stands out.

------
CaliforniaKarl
Is this the only part of MySQL/MariaDB that is known to have a Year-2038
issue?

~~~
tyingq
Yes. UNIX_TIMESTAMP(), FROM_UNIXTIME(), and the TIMESTAMP datatype. Everything
else time related appears to be fine.

------
horizone
Going to be an interesting birthday for me that year. Still surprised that
this hasn’t been fixed yet, we’ve known about it for a while.

------
jolmg
Apparently, it's also an issue with MariaDB.

~~~
OrgNet
I don't know, but I also don't know why anyone didnt make the switch to
MariaDB yet...

~~~
PeterZaitsev
Ignorance is bliss ?

Non of the top Internet dogs - Facebook, Twitter, Uber run MariaDB

~~~
tyingq
There's at least one that does.

[https://www.theregister.co.uk/2013/09/12/google_mariadb_mysq...](https://www.theregister.co.uk/2013/09/12/google_mariadb_mysql_migration/)

And Wikipedia: [https://blog.wikimedia.org/2013/04/22/wikipedia-adopts-
maria...](https://blog.wikimedia.org/2013/04/22/wikipedia-adopts-mariadb/)

~~~
PeterZaitsev
Some do. But MySQL is far much more popular on large scale environments.

In Google BTW I'm not sure how much MySQL/MariaDB is left at all. They have
been moving most of the stuff to Spanner.

------
mackal
Ran into this issue on a project I work on :P

------
bigtunacan
This is going to be great for programmer job security in 2036/2037 if we just
keep it hush hush for awhile longer.

~~~
web007
2038consulting.com is my long-con / retirement plan, but I'd be happy to have
this as a solved problem in the next decade instead.

------
oarabbus_
Reason 34,583,498 to use Postgres instead of MySQL.

~~~
q3k
Also to not use the TIMESTMAP type in general, which is full of similar by-
default footguns (off the top of my head: default 1-second precision,
connection-local timezone autoconversion). At least for non-historic events.

Use uint64 as nanoseconds from epoch. Explicitly convert to/from UTC in your
application code. Smear your leap seconds. This will last you until 2554, by
which time I hope computers as we know are dead. Bonus: these make for decent
strong-read-ordered internal UUIDs, given good retry logic.

~~~
jpeg_hero
I am looking at just this design pattern now (pseudo uuid) can you elaborate
on “given good retry logic”?

~~~
thecopy
I assume that on conflict just retry again, the timestamp will be different.

