3 ms·
> I wish they had not gone with uint32_t for storing mtimes, since they now have to deal with the 2038 problem, sometime in the future. Since uint32_t is unsig
by cesarb 4y ago
> I wish they had not gone with uint32_t for storing mtimes, since they now have to deal with the 2038 problem, sometime in the future.
Since uint32_t is unsigned, wouldn't it be the Y2106 problem instead?
> I am surprised they didn't directly use time_t, so that they wouldn't have to deal with this (since some platforms have already gone to 64 bit time_t)
You mentioned the problem yourself without noticing: some platforms have gone to 64-bit time_t, but others haven't. This is a file format, which can be shared by multiple platforms, so it cannot use types which change size depending on the platform.
- 0x0 4y agoBut you could always a fit a uint32_t mtime in a uint64_t file format field...? Wouldn't it be better to future-proof the file format?
- cesarb 4y agoThat would double the disk space use of that particular file, for something which won't be necessary for more than 80 years (the mtime of a git object or pack file will always be in the past, unless the computer clock is wrong); and when that time arrives, a new file format can be defined (and the old format kept as read-only, with new data being written to the new file).