[tz] question about mktime_tzname()
kre at munnari.OZ.AU
Thu Jan 12 17:21:08 UTC 2017
Date: Thu, 12 Jan 2017 08:05:59 -0800
From: Paul Eggert <eggert at cs.ucla.edu>
Message-ID: <368610ff-5501-d18d-46e8-486588574e2a at 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.
More information about the tz