Sorry your browser is not supported!

As part of stats tracking/storing for my game and, working in Tier 2, I am using the time() function to get the unix time (which is used in several AppGameKit time related functions). This function returns a type of time_t. And therein lies the issue.

On Windows 7 (64bit), time_t comes up as using 8 bytes. In iOS, Mac and Android it is 4 bytes.

In all platforms, int and long are the same size, 4 bytes. We don't worry about the unsigned versions when considering comparison to time_t because time() just might return -1.

This is not necessarily an issue until 2038, when 4 bytes won't be big enough to hold the unix time and we will need 8 bytes.

Since the size of time_t is based on the native compilers, in theory this will be fixed as all systems get updated (or are created new). And the result will be to break files and apps that explicitly store the value in 4 bytes.

Since that is 25 years down the road, I won't sweat if for the moment.

But, it is something everyone is going to start worrying about sometime in the future.

EDIT: I tested and fixed the function to work

Here is a quicky function for handling the issue for AppGameKit files (all assume that the passed file id points to a validly open file in the appropriate input/output mode):


There might be an issue when the local system goes from 4 to 8 bytes for time_t and the stored values had the bit 32 set to 1 (indicating negative). Ideally, you don't store invalid time values (time() returns -1 on error).

Delphi TDateTime is a double floating point value rather than an Int64. But there is a TTimeStamp which is a record containing two int32s.

I agree - don't save anything in a non-portable format.

It's like Y2K back in 1975. Everyone figured whatever they were working on now wouldn't be there then (except the US Feds, they keep old stuff). So no one worried initially and then panicked.

When coding anything with dates, I always assumed that I would want all four digits. But some of the stuff I worked on had been written by others who didn't worry about it. I had fun working on some satellite database and control stuff that all had to be fixed.

And then I spotted this issue. So what if the problem is 25 years away. I think I mentioned to at least one of my clients that there might be this issue in their system (PHP based) when we started on their site 4 years ago. Maybe by then PHP will have addressed the issue.

The adventures of coding across platforms.

This all comes from one simple function (used in lots of languages): time()