Date: Thu, 12 Jan 2017 08:05:59 -0800 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <368610ff-5501-d18d-46e8-486588574e2a@cs.ucla.edu> | I haven't seen that; what implementations are those? Sorry, don't know, that was something I was told about, I have not seen one myself. That's why I don't know for sure what the switchover point is - from what I was told I suspect it might have been arranged so that the earliest representable time is a sensible human date (like Jan 1, 1950 or something) regardless of that not being a nice looking bit pattern (it makes no real difference to the implementation.) | They would not conform to POSIX, Perhaps not, but there are times when functioning rationally so users' systems behave as they should, and conforming to POSIX simply clash, and you can guess which wins then. What's more, POSIX is (supposed to be) documenting what systems actually do, so new systems can be compatible, and applications know what to expect. If this technique became common, posix would be updated to allow it. | which requires that time_t be an integer type that | counts non-leap seconds since 1970. The sane way to use this technique would be to make time_t 64 bits, and use the "off-centre" 32 bit values just when a timestamp is required in a 32 bit field for compatibility. That would be the same way, the same as the sane way for the internet would be to be (almost exclusively) using IPv6 with its bigger addresses, rather than IPv4 which ran out of addresses years ago. But pragmatics aren't always sane. | There are systems with unsigned 32-bit time_t, BSD was almost like that, back around 4.1/4.2 (I forget when exactly). I switched time_t to be unsigned at Berkeley... Unfortunately it broke stuff (particularly the localtime() (of that era) for people west of Greenwich, and caused (time_t)0 to print as something in the 22nd century, rather than Dec 31, 1969 (local time). It never bothered me, as I've (almost exclusively) lived east of Greenwich. Rather than just fix the bugs (it was unclear how much else would break), they reverted the change (it was never in anything released). Pity that. | Microsoft and NetBSD are not the only 32-bit systems with 64-bit time_t; Yes, I know that. The point was just that NetBSD switched a long time ago (6 or 7 years, perhaps more) and there are certainly still places where converting from 32 bit time data into 64 bit time_t's is required (and back again on writes.) The need to support old 32 bit time_t's contiues, both for that, and to retain ABI compatibility for programs last compiled before the switch (the gettimeofday(), stat(), utimes() ... sys calls all require 32 bit time_t interface versions to support that ... NetBSD has all of that.) | I expect these | platforms to supplant their older 32-bit time_t cousins on 32-bit | systems before 2038 rolls around. Once again, the hard problem isn't the system and what it uses as time_t for programs compiled today, it is how to cope with data repositories (like filesystems) that have just 32 bit fields for the time. Do you really believe that all the ext2 filesystems in the world will be gone by then? I know I have disks with filesystems on them that were created in the 1990's (they haven't been spun up in a while, but probably still work). They would (assuming the drives still spin) work just fine on a modern NetBSD (they contain NetBSD filesystems) - perhaps on other *BSDs. Most likely by 2038 I won't care about them (more likely by 2038 there will be no me to care or not care, but that is beside the point) but I cannot help but believe that there will still be people with running filesystems (and similar) which would be annoying to be forced to upgrade. And certainly vendor types (even vendors of free systems) do not like to annoy their users by breaking things needlessly. kre