How to handle not being able to store time in an int?

In some languages, time is stored as the number of seconds from the epoch and stored in an int (Correct me if I am wrong). So we will eventually hit a point where we can't store the current time in an int because there won't be enough bits to hold the time.

Now I know this is down the road, but still, isn't it worth thinking about now?

Anyway, my real question is, should I alw开发者_如何学运维ays use 64 bits to store time or is this something that an operating system might take care of?

Your concern is valid if you want to deal with dates reasonably far in the future. With an unsigned 32-bit integer, you can store up to 2^32 seconds, which is a little over 136 years.

To answer your question, whether you should use 64 or 32 bits to store the amount of seconds depends on your application's needs. If you want to store calendar appointments for an average app, 32 bits is probably enough. On the other hand, if you are building a time machine, using 64 might be a safer bet.

This is actually a well-known problem, similar to the Y2K issue. See http://en.wikipedia.org/wiki/Year_2038_problem for more details.

Modern languages use a long datatype (I.E. java and .net) to store time in milliseconds.

Some platforms / programming languages will run into problems when the number of seconds from the epoch (1970-01-01 00:00 GMT) no longer fits into a 32-bit integer. This does not apply to all platforms nor to all programming languages.

If you use 64-bit integers to count seconds, you're safe for many many more years. Also if you use those 64 bits to count milliseconds, you're still ok for a very long time. I would not expect any problems at all, since you are safe even when you need nine digits to write just the year.