Using a 64 bit timestamp will only move the problem 292 million years forward, so probably the best solution is to use a variable length field.
2038: Only 21 years away
221–230 of 333 posts
Re: 2038: Only 21 years away
#222On a side but related note, I don't understand why many programming languages and databases don't have a positive and negative infinity date placeholder/token value that is standardized and cross platform. Negative infinity date is "past", positive infinity date is "future". This would solve the common problem of what date to use when you are trying to talk about unknown date in the future or unknown date in the past…
There are lots of scenarios where you need to represent an unknown/indefinite date, but this can be done with null; are there any reasonably common scenarios where you need to distinguish between unknown past and unknown future in the same context?
Re: 2038: Only 21 years away
#223Earlier quoted context omitted.
No one is deploying 32-bit linux now, outside of tiny edge cases and mobile. Mobile devices that go in the trash every 2 years. What do you reasonably expect to be around in 2038 in 32-bit form? Once 64-bit processors became mainstream, the 2038 problem pretty much solved itself. There's only disincentives to building a 32-bit system today let alone in 20+ years. Unlike with Y2k where there was nothing but incentives…
It won't be the same magnitude of issues. However, I'm sure there will be plenty of apps on said 64 bit Linux that have issues. I commented about a mysql problem here that exists on 64 bit MySQL, on 64 bit Linux. It's not much of a stretch that some internal apps at a company would have similar issues. Edit: Ntp has something of a protocol issue to be addressed as well.
Yeah. I was working on an IoT system that uses NTP to set time. I generally plan a 20 year life span for tings like this. There's S/W I wrote over 20 years ago that is in devices still in use. The only good thing about this is that I'll not likely be around when trouble crops up. I didn't see any way to accommodate changes that are nearly decades away in code I write today.
Re: 2038: Only 21 years away
#224Earlier quoted context omitted.
I would guess pacemakers don't run Linux. I would be surprised if they run an OS at all. I work on devices that have to survive 20 years on one non-rechargeable and non-serviceable battery, and there's at most a simple scheduler in place to control tasks. We use 32 bits for epoch time, but our epoch starts Jan 1, 2000, so we have 30 years on Linux before this becomes a problem.
This is really interesting! Obviously it is a topic in itself, but do you mind sketching how one develops software in an environment that requires this extreme amount of reliability? If you do not use an existing general-purpose OS, do you even use a MMU? Is it hard real-time? E.g. what language do you use? Is it SW or HW that you "ship"? You probably perform some kind of verification and or validation - how does the…
No MMU. It is hard real-time in the sense that there are events that need to be processed withing a small time window (a few microseconds (with help from hardware typically) to milliseconds).
The product is custom hardware built with off-the-shelf parts like microcontroller, power converters, sensors, memory. Texas Instruments MSP430 family of microcontrollers [1] is popular for this type of application. They are based around MIPS CPU cores with a bunch of peripherals like analog-to-digital converters, timers, counters, flash, RAM, etc.
I don't work on medical devices, so validation is more inline with normal product validation. We certainly have several very well staffed test teams: one for product-level firmware, one for end-to-end solution verification, others for other pieces of the overall solution. We are also heavy on testing reliability over environmental conditions: temperature, pressure, moisture, soil composition, etc.
The firmware is all done in-house written in C. Once in a while someone looks at what the assembler the compiler, but nobody writes assembler to gain efficiency. We rely on microcontroller vendor's libraries for low-level hardware abstraction (HAL), but other than that the code is ours. The tool chain is based on GCC I believe, but the microcontroller vendor configures everything so that it crosscompiles to the target platform on PC.
Debugging is done by attaching to the target microcontroller through a JTAG interface and stepping through code, dumping memory, checking register settings. We also use serial interfaces, but the latency introduced by dumping data to the serial port can be too much for the problem we're trying to debug and we have to use things like togging IO pins on the micro.
We don't model the hardware and firmware and don't do exhaustive all possible inputs test like one would do in FPGA or ASIC verification.
I need to go, but if you have more questions, feel free to ask, and I'll reply in a few hours.
1: http://www.ti.com/lsds/ti/microcontrollers-16-bit-32-bit/msp...
Re: 2038: Only 21 years away
#225Re: 2038: Only 21 years away
#226Earlier quoted context omitted.
You jest, but global IPv6 penetration is at ~16%. It rose ~6% last year, so if linear growth is presumed (and it's actually been growing closer to exponentially, as would be expected) we should hit 20% late this year. I'm hopeful that we'll see some decent pickup of it since AWS finally started offering it. This is global adoption; some countries, including the United States, have already hit 20%. [1]: https://www.go…
>The graph shows the percentage of users that access Google over IPv6. I'm finding it really hard to believe, as someone in Guatemala, that 6% of requests to Google here are made over IPv6. Is there any way to gain more insight? e.g. what ISPs are responsible?
That level of detail isn't published, but most of Guatemala's IPv6 traffic is coming from http://bgp.he.net/AS52362 and http://bgp.he.net/AS23243
Edit: APNIC has similar data published here: https://stats.labs.apnic.net/ipv6/GT
Re: 2038: Only 21 years away
#227Re: 2038: Only 21 years away
#228Let's move to Urbit's 128 bit system: https://github.com/urbit/urbit/blob/master/include/vere/vere...
/* Urbit time: 128 bits, leap-free.
**
** High 64 bits: 0x8000.000c.cea3.5380 + Unix time at leap 25 (Jul 2012)
** Low 64 bits: 1/2^64 of a second.
**
** Seconds per Gregorian 400-block: 12.622.780.800
** 400-blocks from 0 to 0AD: 730.692.561
** Years from 0 to 0AD: 292.277.024.400
** Seconds from 0 to 0AD: 9.223.372.029.693.628.800
** Seconds between 0A and Unix epoch: 62.167.219.200
** Seconds before Unix epoch: 9.223.372.091.860.848.000
** The same, in C hex notation: 0x8000000cce9e0d80ULL
**
** New leap seconds after July 2012 (leap second 25) are ignored. The
** platform OS will not ignore them, of course, so they must be detected
** and counteracted. Perhaps this phenomenon will soon find an endpoint.
*/Re: 2038: Only 21 years away
#229The problem is not with developers or tech savvy people. Everyome will know about this by then and solutions will be applied. The problem is with end users, who will only realize this after the shit hits the fan and their fridge will go crazy or there will be a car crash.
This assumes that any of today's technology will survive 21 years...
Re: 2038: Only 21 years away
#230Earlier quoted context omitted.
This is really interesting! Obviously it is a topic in itself, but do you mind sketching how one develops software in an environment that requires this extreme amount of reliability? If you do not use an existing general-purpose OS, do you even use a MMU? Is it hard real-time? E.g. what language do you use? Is it SW or HW that you "ship"? You probably perform some kind of verification and or validation - how does the…
No MMU. It is hard real-time in the sense that there are events that need to be processed withing a small time window (a few microseconds (with help from hardware typically) to milliseconds). The product is custom hardware built with off-the-shelf parts like microcontroller, power converters, sensors, memory. Texas Instruments MSP430 family of microcontrollers [1] is popular for this type of application. They are bas…
Thank you for your thorough answer.
I am surprised that you do not apply some kind of verification or checking using formal methods, however it might be the case (at least it is the experience I have) that this is still too inconvenient (and so expensive) to do for more complex pieces of software.