Why do many programming languages and applications use integer instead of floating point to represent time?

Question

In my experience, the value of time mostly is represented by integer number, by programming languages (C/Java/Golang/Javascript(*)...), and by databases (MySQL, Postgres...), exceptions maybe some GUI/game engines and I always think it is normal. But when I thought more about this topic, I found that maybe it makes more sense to represent time in floating point instead.

Some of my points:

• The value of time is most frequently used in term of continual sequence of events. (eg: is this contract expired yet, is this football match ended yet...). I don't really remember a time when I need to compare 2 time values are equal. So the precision value of integer is not really useful in this case.
• Secondly, when the precision time is needed (let say we need to represent exact time like 01/01/2020 UTC). The 64-bit floating point can represent it just fine. Likes in javascript, where the value is represent by number - 64-bit floating point number of milliseconds from epoch.
• Using 64-bit floating point to store time is actually more space efficient when you need to represent a fraction of unit. Like in golang and C, you need 2 integers (both 64-bit), 1 for number of seconds from epoch, 1 for number of nano seconds.

I can think of some reasons:

• That's how hardware(CPU?) works?

So what do you think is the reason(s)? Thanks.

(*) Javascript don't have native integer type (until recently with BigInt). So the value of date is actually a number, which is 64-bit floating point, but the value is always integer.

Answer 1

The core idea behind floating point numbers is that you have some number of bits for the mantissa, and then some number of bits to tell where the decimal point is, and of course a bit for the sign.

Let us not get down into how that works in practice. Have a video. Have more videos.

---

Here is the deal, around 0 we get a lot of precision, because we can place the decimal point right at the start of the mantissa, leaving all the bits to express the fractional part.

However as we move away from 0, we need to use more bits to represent the integer part, meaning that we have less bits for the fractional part, and thus less precision.

---

The result, ignoring all technicalities, is that the more we move to the future the less precision we have in the value of time, and thus there are more rounding errors and soon things do not work properly.

Were we using floating point numbers for time, the minimum increment possible would go up every time we need one more bit of the mantissa in the integer part. It does not sound like it is easy to design a clock that works like that.

In fact, some things could stop working at all. For example, if we represent time in seconds, and we run out of bits for the fractional part, anything that needs fractions of seconds does not work.

Do you want that?

---

Computers clocks ultimately boils down to counting oscillations of a vibrating crystal. We count how many times it shakes. And that is fundamentally an integer.

More videos.

Answer 2

Time is an infinite sort of thing. You can go indefinitely into the past, eventually hit the big bang. And maybe you could stop there, but nothing is stopping you. Likewise you can go indefinitely into the future to the (probable) heat death of the universe. You might stop there, but nothing is stopping you. And you can slice an individual second down to fractions of a second, millionths of a second, and so on until you get to an infinitesimal instant in time.

Well computers can't store infinite potential values. You need to make some approximation somewhere, or add some level of granularity to make it prudent. Thus we end up with encodings like "seconds since 1/1/1970 Midnight UTC". This provides a tradeoff between precision, range, and storage size. Encoding all of those values in bits takes the same number of bits, regardless if you view them as ints or floats. So programmers use ints so they can focus on the time encoding itself, without having to also worry about floating point encoding.

Answer 3

Go back 35 years, and floating point was expensive. Two orders of magnitude slower than integers. That was a good reason back then. And later on nobody wanted to change interfaces.

Objective-C and Swift give dates as number of seconds in GMT since some unspecified but constant reference date, as double precision floating point numbers, which avoids confusion (is it seconds, milliseconds, or what), is easier to use in code, and nowadays is faster. And it gives you sub-microsecond resolution.

The numbers of seconds in this implementation assume that there are no leap seconds. So the seconds counted are not fixed physical length. Well, it makes life easier for most people.

Answer 4

Floating point gives the illusion of accuracy. In the end it's stored as a 32 bit or 64 bit "integer" value anyhow.