Most computer systems I know use Unix timestamps to store time, i.e. they record the number of seconds that have elapsed between the Unix epoch (January 1, 1970) and the date being stored. As long as the data only needs to preserve second-precision, dates and times are efficiently stored as integers.

But not Google Sheets.

Google Sheets stores dates by counting the number of days that have elapsed between the arbitrary start date of December 30, 1899 and the date being stored. This is easy to confirm by formatting dates as numbers:

Google Sheets does not use Unix time to store dates.

This means that dates before the start date are represented as negative numbers:

Dates before December 30, 1899 are stored as negative numbers.

And sadly, that times are stored using decimals:

Google Sheets stores times with floating point numbers.

After playing around with Google Sheets, I quickly realized that many date functions didn't work with any dates that needed to be stored as negative numbers. While unfortunate, I don't have many use cases for dates in the 1800s or earlier, so I consider this an acceptable "oversight."

Many Google Sheet functions don't work with older dates.

That said, I don't understand the decision to store elapsed days instead of elapsed seconds. And it turns out that Excel does the same thing too. Well, almost. Excel stores elapsed days, but it's arbitrary start date is January 1, 1900, which is at least a nice easy date to remember. So why does Google Sheets use a start date 2 days earlier than that? I have no idea!

And sure, the Unix epoch seems fairly random, but the reason for this start date is well-known. Unix time was developed in the early 1970s, when most hardware systems' clocks ran at 60Hz. The first Unix time implementations thus counted the number of 1/60th-seconds instead of seconds, and they did it on 32-bit machines. This meant that integer overflows would happen after 828 days (~2.5 years), so the epoch was set to be in the recent past. Initially, it was January 1, 1971.

When the implementation was later changed to count seconds instead of 1/60-th-seconds, a 32-bit integer could then span over 100 years of time. It was no longer essential to start counting from the immediate past, and so the epoch was moved to January 1, 1970 instead. Now, the new integer overflow is set to happen in 2038 and is named Y2K38. It's only 16 years away! Yikes!