Question

From /usr/include/time.h:

/* Used by other time functions. */
struct tm
{
int tm_sec;. . . /* Seconds..[0-60] (1 leap second) */
int tm_min;. . . /* Minutes..[0-59] */
int tm_hour;. . . /* Hours.. [0-23] */
int tm_mday;. . . /* Day... [1-31] */
int tm_mon;. . . /* Month.. [0-11] */
int tm_year;. . . /* Year.- 1900. */
int tm_wday;. . . /* Day of week..[0-6] */
int tm_yday;. . . /* Days in year.[0-365].*/
int tm_isdst;.. . /* DST... [-1/0/1]*/

#ifdef. __USE_BSD
long int tm_gmtoff;. . /* Seconds east of UTC. */
__const char* tm_zone;. / Timezone abbreviation. */
#else
long int __tm_gmtoff;.. /* Seconds east of UTC. */
__const char* __tm_zone;. / Timezone abbreviation. */
#endif
};

If you want to write this structure to a file, and you want your program to read it back and to have multi-arch support (ie 32 bit version writes it, 64 bit version reads it), you’ll have to do some hacks to make sure that it’s the same size for each system. Does anyone know of a better way to keep time stamps that are architecture independent? Eg, I want to be able to write some structure eg, time_t, or struct tm to a file and read it back for any architecture. Does anyone have any experience or advice for this? Is struct tm even the best way to store a time stamp in C/C++? I realize there’s a fair bit of overhead using this structure.

I currently have redefined the structure to the following:

//Force 32 bit format and space requirements
struct tm32
{
int tm_sec;. . . /* Seconds..[0-60] (1 leap second) */
int tm_min;. . . /* Minutes..[0-59] */
int tm_hour;. . . /* Hours.. [0-23] */
int tm_mday;. . . /* Day... [1-31] */
int tm_mon;. . . /* Month.. [0-11] */
int tm_year;. . . /* Year.- 1900. */
int tm_wday;. . . /* Day of week..[0-6] */
int tm_yday;. . . /* Days in year.[0-365].*/
int tm_isdst;.. . /* DST... [-1/0/1]*/

int tm_gmtoff; // this does nothing but hold space
int tm_zone; // this does nothing but hold space
};

Since the functions (mktime(), time(), gmtime(), strftime()) I’m using to manipulate the struct tm don’t seem to even look at the last two fields in the struct tm structure, I simply use integers as place holders in their positions so that the size will always be the same. However, I’m still looking for a better solution to this…

EDIT: The int types I used in the above fix could be int32_t or whatever fixed width type chosen.

Answer 1

Ensuring that data saved is written in a way that can be read back on the desired platforms would not qualify as a “hack”, in my opinion. Blindly saving out a (probably packed) structure in binary format and expecting to read it back easily and portably would, however.

You need to handle each field separately, since the compiler might add padding between the fields which would appear in a “binary dump” of the struct, but that is completely compiler-dependent and thus very bad for interoperability between platforms.

I would probably decide on a reasonable precision for the native int fields of the structure, say 32 bits, and write something like this:

void tm_serialize(FILE *out, const struct tm *tm)
{
  int32_serialize(out, tm->tm_sec);
  int32_serialize(out, tm->tm_min);
  /* and so on */
}

struct tm tm_deserialize(FILE *in)
{
  struct tm tm;
  tm.tm_sec = int32_deserialize(in);
  tm.tm_min = int32_deserialize(in);
  /* and so on */
  return tm;
}

Where, of course, int32_serialize() and int32_deserialize() simply write (and read) a binary representation of the 32-bit integer in a known (such as big-endian) format which is well-defined and easy to read back on any platform.

UPDATE: Serializing strings can of course be done in the exact same way, one popular format is the same as C’s in-memory layout, i.e. 0-terminated char array. Then you’d just have:

void string_serialize(FILE *out, const char* string);
int  string_deserialize(FILE *in, char *string, size_t max);

Here, the string_deserialize() function must have a buffer size limit so it doesn’t overflow anything by readin too much. I imagined the return value to indicate success/failure, so the calling code can take whatever measures it wants to.

In the above, I wasn’t aiming for a space-minimized serialization, as a commenter pointed out many of the fields that are int at run-time don’t really need all that precision, so they could be serialized into something smaller. If you wanted to do that, it would of course be trivial to invent appropriate functions like int8_serialize() and so on, and use the right one for each field.