Anno 2038 problema [chiuso]

Qual è la probabilità che il problema dell'Anno 2038 sia molto problematico?

Ho riscontrato questo problema in un sistema Linux incorporato che doveva gestire le date oltre il 2038 in alcuni certificati crittografici a lungo termine, quindi direi che la somiglianza dipende dal dominio dell'applicazione.

Mentre la maggior parte dei sistemi dovrebbe essere pronta ben prima del 2038, se ti ritrovi oggi a calcolare le date in un futuro molto lontano, potresti avere un problema.

Penso che questo sarà un problema significativo, molto più pernicioso rispetto ai problemi Y2K del 1999/2000 perché il codice interessato è generalmente di livello inferiore (è CTIME) e quindi è più difficile individuare i luoghi in cui il tempo viene archiviato in quel modo.

A complicare ulteriormente le cose, il fatto che Y2K fosse percepito come uno squib umido renderà più difficile attirare l'attenzione sul problema nel periodo precedente all'evento.

Riferimenti culturali:

Cory Doctorow stava provando un nuovo modello per commissionare / pubblicare racconti con licenze aperte, e io ho suggerito un tema del 2038 o uno di essi, che ha fatto brillantemente in Epoch: http://craphound.com/?p=2337

Alcuni anni fa, c'erano già segnalazioni di problemi, in settori come i programmi ipotecari che effettuavano calcoli su prestiti trentennali: 2008 + 30 = 2038.

Un sistema operativo a 64 bit è in definitiva irrilevante per il problema del 2037. (CTIME si avvicina al 2037 rispetto al 2038).

La domanda non è la profondità in bit del sistema operativo, piuttosto come fa il sistema operativo a memorizzare il tempo. O in che modo la colonna del database sceglie di memorizzare l'ora. O in che modo questo attributo della sintassi dei servizi di directory memorizza l'ora nel back-end.

Questo è un problema molto più grande di quanto si pensi, dal momento che è così endemico e comune aver usato i contatori di tempo a 32 bit.

Ogni istanza che memorizza il tempo deve essere rivisitata e tutte le API aggiornate e anche tutti gli strumenti che lo utilizzano.

I livelli di astrazione che ti consentono di impostare l'ora tramite un formato orario leggibile dall'uomo, anziché i dati grezzi scritti rendono più semplice, ma questo è solo un caso.

Ho il sospetto che questo sarà un affare molto più grande di quanto la maggior parte della gente pensi.

Questa è la mia opinione, ma questo problema è dovuto a un problema del contatore a 32 bit, oggi la maggior parte dei SO sono aggiornati per gestire il tempo su 64 bit (almeno su computer a 64 bit), quindi immagino che tutto il sistema operativo e il software saranno pronti a lungo tempo prima del 2038, diciamo 2020. Quindi potresti avere problemi solo se nel 2038 continuerai a eseguire software dal 2020.
Probabilmente non sarà un problema in quasi tutti i casi. Io spero.

Non è un grosso problema.

Durante il primo blitz Y2K, in cui i fornitori di software e hardware dovevano certificare i loro prodotti come "Y2K compliant" per essere venduti (ricordo che i cavi di rete su PC Connection erano certificati Y2K), molte aziende hanno effettuato controlli dettagliati di tutto , impostando gli orologi in futuro e testando.

All'epoca, poiché il costo dei test era così elevato, quasi sempre testarono con diverse date, come 1/1/99 (alcuni sviluppatori potrebbero aver usato 99 come sentinella), 31/12/99, 1/1 / 00, il balzo del 2000, 19/01/38 e molti altri. Vedi qui per un noioso elenco.

Quindi credo che qualsiasi software importante che esisteva nel 1999 probabilmente non avrà 2038 bug, ma potrebbe esserci un nuovo software scritto da allora da programmatori ignoranti. Dopo l'intero debacle di Y2K i programmatori in genere sono diventati molto più consapevoli dei problemi di codifica della data, quindi è improbabile che abbia un impatto tanto grande quanto lo era Y2K (che, di per sé, era qualcosa di anticlimax).

I sistemi a 32 bit ancora in esecuzione saranno un problema.

#include <time.h>
#include <stdio.h>

int main() {
  time_t t = (time_t)(1L << (sizeof(time_t)*8 - 9));
  printf("%d\n", sizeof(time_t));
}

dovrebbe essere 1 invece di 9 ma ctime non gestisce una data più grande:

8 - Sun Jun 13 07:26:08 1141709097

Il tempo del mio sistema (ovviamente a 64 bit) può durare anche 1 milione di anni in più. La soluzione è aggiornare i sistemi a 64 bit.

Il problema è che i programmi potrebbero non gestirlo. Soprattutto vecchio, corretto e non mantenuto. Gli sviluppatori sono abituati ai seguenti fatti:

• intsono 32 bit (in effetti sono conservati come 32 bit su sistemi a 64 bit, tra l'altro perché si supponeva che fossero sempre 32 bit)
• La maggior parte dei tipi (come time_t) può essere tranquillamente lanciataint

Nel famoso software FLOSS entrambe le cose probabilmente non passeranno attraverso la recensione "molti occhi". Da meno popolare e proprietario dipenderà in gran parte dall'autore.

Immagino che nel mondo libero * nix il 2038 sarà "inosservato" mentre mi aspetto problemi su piattaforme "proprietarie" (cioè quelle con un gran numero di software proprietarie) - specialmente se una parte crutiale non verrà mantenuta.

Se è qualcosa come Y2K, alcune persone sono già state colpite e stanno cambiando software, ma la maggior parte degli sviluppatori lo ignorerà fino a quando negli anni '30, probabilmente 2035 o giù di lì, a quel punto ci sarà molto lavoro fatto e qualcuno abbastanza vecchio conoscere K&R C e non ancora troppo senile potrà improvvisamente contrarre per un sacco di soldi. La transizione effettiva mostrerà molte cose non ancora fatte, probabilmente nessuna di quelle così importanti.

Il problema Y2K era rappresentato da due carte che rappresentano l'anno anziché quattro.

Molti sistemi non hanno avuto modo di distinguere tra il 2000 e il 1900 poiché conservavano solo gli "00".

Quasi tutti i sistemi ora utilizzano 4 caratteri per memorizzare l'anno oppure usano una libreria di qualche tipo.

Quindi lasciamo tutti preoccuparsi dell'anno 10000 (Y10K) invece. Tranne che per gli scrittori di SO e Library ...