[HN Gopher] Hexadecimal clock counting down to 2038 problem
___________________________________________________________________
Hexadecimal clock counting down to 2038 problem
Author : PaulRobinson
Score : 93 points
Date : 2023-09-16 06:14 UTC (1 days ago)
(HTM) web link (retr0.id)
(TXT) w3m dump (retr0.id)
| fguerraz wrote:
| Why a signed int?
| vore wrote:
| time_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.
| uoaei wrote:
| Converting to unsigned int only changes the first digit (6
| becomes e) but I think `e5075ea9` is a little easier to
| reason about.
| [deleted]
| CableNinja wrote:
| Afaik this is so that you can go back in time before epoch
| (less than 0)
| avgcorrection wrote:
| Then why not start the epoch however far back they thought
| they need to go back? Maybe a naive question.
| umanwizard wrote:
| Whether 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 wrote:
| Sure. 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.
| arcticbull wrote:
| You may need an arbitrary distance back in time, so
| really any epoch is as good as any other. So if you're
| going to pick arbitrarily, zero around where most numbers
| are going to be when you set the standard seems to make
| sense.
| faraggi wrote:
| Was the negative sign commonly used for delta times?
| SAI_Peregrinus wrote:
| The epoch was set very close to the start of UNIX (it
| started development in 1969, _before_ epoch 0). Negative
| epoch dates are quite common, e.g. many people 's
| birthdays.
| gene91 wrote:
| In 1970, I suppose there are many people whose birthdate
| is before 1901-12-13?
| umanwizard wrote:
| Using a signed int allows you to represent times before 1970.
| This is not just theoretical; it's done in the wild.
| Materialize, the data warehouse software I work on, used to
| have a bug causing it to fail on negative Unix times and we
| found out when somebody tried to load in a database with human
| dates of birth.
| RedNifre wrote:
| My 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 wrote:
| Should dates be strings?
| somewhereoutth wrote:
| Yes 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 wrote:
| It'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.
| paulddraper wrote:
| > CSV
| dragonwriter wrote:
| Not really.
|
| I mean, sure, serialize them as ISO8601 strings, but, no,
| dates are fundamentally not strings, and that shouldn't be
| their basic internal representation in most sane systems.
|
| In CSV, though, everything is strings. But the question there
| is _what_ string format.
| [deleted]
| ooterness wrote:
| ISO8601 / RFC3339 for life.
| quickthrower2 wrote:
| That is not the real 2038 problem.
|
| But cool clock, really love it!
| bloopernova wrote:
| If 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 wrote:
| > 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 wrote:
| Yes, 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.
| simonkagedal wrote:
| I love that hexadecimal-analog clock.
| bloopernova wrote:
| I know, right? I really want one for my wall.
| xwdv wrote:
| Why 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!
| faeriechangling wrote:
| I suppose they figured, quite reasonably, that things written
| in the 60's would be updated by 2038 and to address this
| problem was premature optimisation. In the 2000s 64-bit went
| mainstream which gave us a solid ~30 years to tackle this
| issue. 32-bit time was introduced in a time where there was a
| very real argument for it in terms of performance, simplicity,
| and cost.
|
| I'm not even sure if in hindsight the wrong decision was made.
| ksenzee wrote:
| Because 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 wrote:
| IPv6 just popped in to say hi
| Kerb_ wrote:
| >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
| umanwizard wrote:
| How much code have you written that you expect to still be in
| use 68 years from now?
| quickthrower2 wrote:
| For someone adult in 2000, 2038 might be retirement age, so
| they are probably investing in their pension and paying off the
| mortgage assuming 2038 is coming, but then at work it is like
| "wont be here when that happens!"
| snickerbockers wrote:
| See: climate change, American social security administration,
| preservation of ancient manuscripts and ruins, etc...
|
| But at least Jeff bezos is putting his fortune into an immortal
| clock in the desert (I'm being sarcastic but the desert clock
| is actually real and supposedly a gift to future generations as
| if measuring time wasn't a problem that stone-age civilizations
| all over the world were able to solve independently).
| Someone wrote:
| Why do you assume they didn't consider it? Memory was too
| scarce and too expensive to do it.
|
| Unix time is 32 bits, so I guess Unix time was invented a bit
| later, but around 1970, when Unix was written, RAM cost around
| $700k/megabyte, or, ballpark, $1/byte
| (https://jcmit.net/memoryprice.htm)
|
| Even if you had infinite memory, you couldn't use much of it in
| your computer. The PDP-7 that Unix started life on topped out
| at 144kB, the PDP-11 that it was soon ported to at 288kB (64k
| 36-bit words), and many installs wouldn't have that.
| matheusmoreira wrote:
| Can't we fix this once and for all using variable length
| integers?
|
| https://en.wikipedia.org/wiki/Variable-length_quantity
|
| This way the counter can scale up to any number of bits.
| paulddraper wrote:
| That's unnecessarily complicated.
|
| A 64-bit signed Unix time fixes this for 25x longer than the
| remaining lifetime of the sun.
| Kamq wrote:
| Our descendants around alpha centauri are going to have so
| much legacy code to upgrade.
| randyrand wrote:
| That would add a lot of complexity to structs that want to have
| a static size.
|
| i'd just pick a huge number and move on.
| layer8 wrote:
| Discussed four days ago (15 comments):
| https://news.ycombinator.com/item?id=37492371
| 29athrowaway wrote:
| Mainframe software will be the most painful to fix.
| ogogmad wrote:
| Obligatory: Could we use LLMs?
| tylerrobinson wrote:
| In 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-...
| snickerbockers wrote:
| Also 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.
| jcul wrote:
| Other interesting time storage issues, including the Y2038
| problem.
|
| https://en.m.wikipedia.org/wiki/Time_formatting_and_storage_...
| johnea wrote:
| This 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...
| mcint wrote:
| Pretty 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
|
| Other thread of his blog domain
|
| https://www.da.vidbuchanan.co.uk/blog/unix-clock.html
|
| 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.
| kaoD wrote:
| Not obvious indeed, but after some thought it actually feels
| natural to have INT32_MIN (a negative number) at the bottom.
| bcraven wrote:
| 'Straight down' is how the UK gameshow 'Countdown' finishes its
| iconic period, perhaps this is an influence.
| turnsout wrote:
| This makes me nostalgic for the mid-2000s when all the geeks had
| binary watches
___________________________________________________________________
(page generated 2023-09-17 23:00 UTC)