201–210 of 214 posts
Earlier quoted context omitted.
Making time_t unsigned would break the ability to refer to times before 1970. Existing code that deals with 32-bit timestamps almost universally assumes that (time_t)0 is 1970-01-01 00:00:00 UTC. Updating that code to guess a different epoch would be more work (with more inevitable bugs) than keeping a fixed epoch and using 64 bits. It's already 64 bits (and signed) on a lot of systems.
What on earth is that good for? Seems like an extreme niche.
Earlier quoted context omitted.
There's an extra apostrophe there... this is addressed toward the end of the novel.
Yes, it's not "The end of this particular rainbow", it's "rainbows have an end". It bugged me until I got to that part of the book.
Earlier quoted context omitted.
We're not talking about C, were talking about how it works on the computers.
Many if not most of the embedded/long term systems are implemented in C. If a variable is declared signed, overflowing cases may and often are "optimized" away. IIUC, GP's foo() would likely be optimized to { return true; }, and so would similar timestamp overflow checks.
Earlier quoted context omitted.
We're not talking about C, were talking about how it works on the computers.
Many if not most of the embedded/long term systems are implemented in C. If a variable is declared signed, overflowing cases may and often are "optimized" away. IIUC, GP's foo() would likely be optimized to { return true; }, and so would similar timestamp overflow checks.
Given this thread of subargument, making the difference between 32-bit unsigned numbers is MORE DEFINED than using signed integers.
-------
IE: If your code was correct with "int timestamp", it will be more correct with "unsigned int timestamp".
In any case, "int" or "unsigned int" based timestamp manipulation wouldn't be like the code you suggested, but instead "int difference = x - y".
In the signed integer case, "difference" is (conceptually) negative, while in the unsigned integer case, "difference" is guaranteed to have overflow. Both cases are conceptually correct with regards to the difference of timestamps.
Earlier quoted context omitted.
Why will PIC's fail sooner? (and which ones, 8, 16 or 32bit?)
I worked with the 16 bit PIC24f. I don't have the source handy to check, but according to a forum entry "The provided gmtime() actually fails earlier than 2038. The year wraps around when the time_t input goes beyond 0x7C55817F or Thu Feb 7 06:28:15 2036." [1] 1: https://www.microchip.com/forums/m522929.aspx
Earlier quoted context omitted.
All observers observer all clocks to advance monotonically forward in time, regardless of their location or relative speed, unless the clock is moving at the speed of light. But the rate that each clock is observed to advance at depends on things like relative speed, acceleration, and the curvature of spacetime.
... unless it's the system clock in Linux, with the hardware RTC set to be interpreted as local time, and one is watching a system boot on a machine that is set up as east of the Prime Meridian (i.e. the hardware RTC is ahead of UTC). (-: * https://unix.stackexchange.com/a/600490/5132
what would be the problems with choosing a new epoch (i.e. one where jan 1 is the same day of week as jan 1, 1970 and is 2 years before a leap year. (perhaps doesn't exist).
The worse case I see is that apps that calculate years internally (instead of via a shared library or like) would calculate them incorrectly. I'm wondering if this wouldn't be something that could be massaged around. Of course, it just pushes the problem down the road.
it also makes timestamps like this incompatible between systems that have different epochs, which could be an issue.
as I said, naive (possibly stupid) Q, just wondering if people have actually talked about it?
weird Q I was wondering about in regards to the epoch. (perhaps a stupid Q) what would be the problems with choosing a new epoch (i.e. one where jan 1 is the same day of week as jan 1, 1970 and is 2 years before a leap year. (perhaps doesn't exist). The worse case I see is that apps that calculate years internally (instead of via a shared library or like) would calculate them incorrectly. I'm wondering if this wouldn…
https://en.wikipedia.org/wiki/Year_2038_problem#Possible_sol...
https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoc...
Earlier quoted context omitted.
IIUC unix timestamp simply counts seconds (well defined interval of time) from epoch onwards. It is then up to different calendars to interpret this number as a given day / hour /... This is the beauty of it - it is always an accurate (well, at low speeds at least ;) ) measure of time. In other words, no, some days might not last 86400 seconds.
This is not correct. UNIX timestamps always have 86400 seconds per day, and consequently, they do not actually count the number of seconds since the epoch.
