9 ms·
Hexadecimal clock counting down to 2038 problem
- 29athrowaway 3y agoMainframe software will be the most painful to fix.
- ogogmad 3y agoObligatory: Could we use LLMs?
- tylerrobinson 3y agoIn case you missed it, that’s IBM’s plan (or at least their marketing team’s plan)! https://arstechnica.com/information-technology/2023/08/ibms-generative-ai-tool-aims-to-refactor-ancient-cobol-code-for-its-mainframes/amp/ https://arstechnica.com/information-technology/2023/08/ibms-...
- snickerbockers 3y agoAlso obligatory: calendar based cryptocurrency that measures time on the blockchain and also incidentally makes its creator rich by providing him with the largest initial allocation of currency.
- 29athrowaway 3y agoLLMs can suggest migrated code but you still have to review it and test it. And you have to review not only what it migrates but also what it does not. So it does not save you much time.
- everythingctl 3y agoWould any “real” mainframe software (not Linux on z) use Unix epoch dates though? I’d have thought mainframe dates were mostly binary coded decimal in EBCDIC and already futureproofed during the y2k mania.
- turnsout 3y agoThis makes me nostalgic for the mid-2000s when all the geeks had binary watches
- naikrovek 3y agobinary watches are pure vanity. no one wore binary watches because they were useful, they weren't useful at all, unless your goal was socializing. people wore binary wristwatches because they wanted to be seen wearing binary wristwatches, that's it. to me, activities like this are the absolute epitome of waste and vanity. (both are bad, if I'm not being clear, here.) but, I also think that it's perfectly ok for people to like whatever they want to like, as long as it doesn't hurt anyone, so I guess it's like "I don't like what you're saying, but you absolutely have the right to say it."
- turnsout 3y agoI definitely knew at least one engineer who learned to read their binary watch. The goal was absolutely social. It's a conversation-starter, for a crowd that, let's face it, could use more practice having conversations. You're right that it's wasteful—those watches are mostly e-waste at this point. But so are all the electronics we've bought in the past 20 years. I'm typing on future e-waste right now!
- RedNifre 3y agoMy bank is now y2.1k bug ready: In their CSV export, they changed the date format for the year back to 2 digits. It only takes 23 years to forget history.
- ogogmad 3y agoShould dates be strings?
- paulddraper 3y ago> CSV
- ooterness 3y agoISO8601 / RFC3339 for life.
- deleted 3y ago[deleted]
- somewhereoutth 3y agoYes absolutely. Dates are too complicated, requiring to much context, with too much to go wrong, for any non human readable format. At least with strings other systems have half a chance of parsing them correctly, or at least parsing them in a transparent manner. Or to put it another way, they cannot be trusted to engineers to get it right every time. Let's face it, even something as simple as floating point numbers have serious issues when implemented in computer systems (so another candidate for strings quite frankly - notable that JSON is strings all the way through).
- landryraccoon 3y agoIt’s not just a matter of trust. Locale specific datetimes in the future are simply not computable to a point on a number line in the general case. Some locales have date changes that must be determined by the local government every single year. Israel is an example of such a case.
- johnea 3y agoThis is displayed whnever I open a new terminal: Welcome to workstation - Today is Sunday, September 17th 2023 There have been 53 years and 272 days in the unix epoch! There are 14 years and 127 days until the 32-bit time apocalypse Prepare yourself...
- simonkagedal 3y agoI love that hexadecimal-analog clock.
- bloopernova 3y agoI know, right? I really want one for my wall.
- mcint 3y agoPretty cool! Although it's not obvious, without reading, that the issue falls at clock-bottom, which is counter to analog clock convention, both for 12 hour and 24 hour clocks. I would encourage some coloring, shading, or a larger mark. Logically, reaching for a justification, an explanation, sure, it's reasonable that the MSB flips halfway around, but again it differs from the analog clock reading conventions. v2 (+/v2.html) which he posted on another thread, does make it clearer https://retr0.id/stuff/2038/v2.html https://retr0.id/stuff/2038/v2.html Other thread of his blog domain https://www.da.vidbuchanan.co.uk/blog/unix-clock.html https://www.da.vidbuchanan.co.uk/blog/unix-clock.html https://news.ycombinator.com/item?id=37492371 https://news.ycombinator.com/item?id=37492371 The color separation is also a bit large, mainly 2-3 and 3-4, while 1-2 are similar but distinct.
- fguerraz 3y agoWhy a signed int?
- vore 3y agotime_t has historically been a typedef to a 32-bit signed integer, so the signedness is baked into a lot of legacy software still running today.
- CableNinja 3y agoAfaik this is so that you can go back in time before epoch (less than 0)
- avgcorrection 3y agoThen why not start the epoch however far back they thought they need to go back? Maybe a naive question.
- School-Cotton 3y agoWhether you make 0 be in 1902 and use an unsigned type, or make 0 be in 1970 and use a signed type, the range of representable dates is the same.
- avgcorrection 3y agoSure. But (and what I should have added) I don't think they would need to go back that far. But you're right, you can get the same results with both.
- School-Cotton 3y agoAs others have pointed out in the thread, it was already not enough to represent the dates of birth of plenty of people who were still alive in 1970.
- xwdv 3y agoWhy didn’t past generations consider these ramifications for future generations? 2038 must have seemed so far away, but now it’s so close I bet even in 2038 and beyond people will still be reading this comment. Maybe they will be cursing us for the tech debt they inherited!
- ksenzee 3y agoBecause the hardware didn’t support it. We knew in 1999 that the 2038 problem existed, for example, but our choices were a) stop representing dates as seconds since the Unix epoch, and introduce who knows how many bugs in every imaginable piece of software, or b) kick the can down the road until 2038, when presumably everything would support 64-bit integers. b) was the obvious choice then, and it still looks like the right choice to me in hindsight.
- quickthrower2 3y agoIPv6 just popped in to say hi
- aib 3y agoIPv6 with a 16-bit payload size limit?
- zokier 3y ago64 bit ints (long long) have been used on 32 bit platforms since mid-80s (ILP32LL)
- Kerb_ 3y ago>Why didn’t past generations consider these ramifications for future generations? 2000 must have seemed so far away, but now it’s so close I bet even in 2000 and beyond people will still be reading this comment. Maybe they will be cursing us for the tech debt they inherited! ~Not enough people in 1985, I guess. They seem more concerned with leap years than anything. https://groups.google.com/g/net.bugs/c/ZGlqGwNaq3I https://groups.google.com/g/net.bugs/c/ZGlqGwNaq3I
- 3y ago
- layer8 3y agoDiscussed four days ago (15 comments): https://news.ycombinator.com/item?id=37492371 https://news.ycombinator.com/item?id=37492371
- jcul 3y agoOther interesting time storage issues, including the Y2038 problem. https://en.m.wikipedia.org/wiki/Time_formatting_and_storage_bugs https://en.m.wikipedia.org/wiki/Time_formatting_and_storage_...
- matheusmoreira 3y agoCan't we fix this once and for all using variable length integers? https://en.wikipedia.org/wiki/Variable-length_quantity https://en.wikipedia.org/wiki/Variable-length_quantity This way the counter can scale up to any number of bits.
- School-Cotton 3y agoIt is already fixed once and for all by using i64, unless you care about dates hundreds of billions of years in the future or past.
- matheusmoreira 3y agoOr unless you use more precise clocks. Nanosecond resolution cuts those billions down to hundreds of years. We're probably gonna get picosecond or femtosecond resolution clocks someday. Then we're gonna have yet another one of these threads and someone's gonna tell me 128 bits will fix it forever.
- School-Cotton 3y agoThose are already different types, though. What type it makes sense to use for seconds isn’t necessarily the same as what type it makes sense to use for other time units. I agree that using 128 bits makes sense for nanoseconds if for some reason you care about nanosecond-precision timestamps merely hundreds of years in the future or past. I find it hard to believe we will ever have femtoseconds-resolution timers or ever even care what femtosecond an event happened at. But even if we do, incidentally, 128 bits is still fine. i128 femtoseconds will overflow in approximately the year 1000000000000000000000000. So, I don’t think there’s any practically useful time unit for which we need variable length integers and can’t just use i128.
- matheusmoreira 3y ago> I find it hard to believe we will ever [...] care what femtosecond an event happened at GNSS satellites require precise clocks to accurately calculate ranges. Signals travel at the speed of light so small imprecisions result in large errors: timing differences of one millisecond produce about 300 kilometers of error in distance measurements. It seems GPS satellites have clocks accurate to within 40 nanoseconds. One nanosecond gives around 30 cm of error, 40 nanoseconds would give about 12 meters. Picosecond resolution would bring those errors down to the millimeter and micrometer ranges. Femtosecond resolution would bring the errors down to nanometers.
- quickthrower2 3y agoThat is not the real 2038 problem. But cool clock, really love it!
- phatskat 3y agoWhat is the real 2038 problem?
- bloopernova 3y agoIf you like to have the Unix epoch in your prompt, you can do something like this: function prompt_epoch() { printf -v COMMA_EPOCH "%'d" ${EPOCHSECONDS} p10k segment -f 66 -t ${COMMA_EPOCH} } EPOCHSECONDS relies on `zmodload zsh/datetime`. printf -v creates a variable rather than output text. p10k segment is just a function that powerlevel10k uses, you don't have to use it. COMMA_EPOCH is just the current Unix time separated by commas every 3 digits. If you wanted your own countdown, you could easily do `2147483647 - EPOCHSECONDS` and display that time instead. EDIT: and if you want to mimic that oh-so-cool clock, you could do: printf '%x\n' $EPOCHSECONDS or assign that to a variable with printf -v, then split the string into pairs. Mimicking the colours of the clock would be fairly trivial too.
- codetrotter 3y ago> EPOCHSECONDS relies on `zmodload zsh/datetime` Is there any advantage to using that module instead of invoking date +%s I use zsh but I don’t have any addons installed or anything. So for me it is less work to call date +%s instead
- bloopernova 3y agoYes, it doesn't fork a separate process. I doubt I could really tell the difference in prompt responsiveness, but I liked learning about the printf -v COMMA_EPOCH method.
- alex_young 3y agoWhy hex though?
- graypegg 3y ago2 hex characters represent 1 byte (8bits) so it lines up nicely if you’re looking at where memory gets saved, and will align nicely with big rollovers since it’s a power of 2 radix. FFFFFFFE => FFFFFFFF => 00000000, rather than 4294967294 => 4294967295 => 0 or the equivalent formatted as a date string. Feels better for a count down thing. Plus bonus points for, when mentioning how 64 bit ints are the solution here: FF FF FF FF (u32) = 00 00 00 00 FF FF FF FF (u64) makes it pretty clear what the trade off in memory usage is vs range gained.