| dbpprop:abstract
|
- The year 2038 problem (also known as Unix Millennium bug, or Y2K38 by analogy to the Y2K problem, known as the millennium bug) may cause some computer software to fail before or in the year 2038. The problem affects all software and systems that store system time as a signed 32-bit integer, and interpret this number as the number of seconds since 00:00:00 January 1, 1970. The latest time that can be represented this way is 03:14:07 UTC on Tuesday, 19 January 2038. Times beyond this moment will "wrap around" and be stored internally as a negative number, which these systems will interpret as a date in 1901 rather than 2038. This will likely cause problems for users of these systems due to erroneous calculations. Further, while most programs will only be affected in or very close to 2038, programs that work with future dates will begin to run into problems much sooner. For example, a program that works with dates 20 years in the future will have to be fixed no later than in 2018. Because most 32-bit Unix-like systems store and manipulate time in this format, it is usually called Unix time, and so the year 2038 problem is often referred to as the Unix Millennium Bug. However, any other non-Unix operating systems and software that store and manipulate time this way will be just as vulnerable.
- Das Jahr-2038-Problem könnte zu Softwareausfällen im Jahr 2038 führen. Dieses Problem ist auf EDV-Systeme beschränkt, die den POSIX-Zeitstandard benutzen und time_t als vorzeichenbehaftete 32-Bit-Binärzahl definieren. POSIX zählt die seit dem 1. Januar 1970 abgelaufene Zeit in Sekunden. Am 19. Januar 2038 um 03:14:08 Uhr UTC wird die Anzahl der vergangenen Sekunden die Kapazität einer 31-Bit-Zahl (maximal 2147483647) überschreiten. Das signifikanteste Bit wird laut Konvention dazu verwendet, positive und negative Zahlen zu unterscheiden, so dass die Zählung bei einer Überschreitung des Wertes 2147483647 (binär 01111111111111111111111111111111) in den negativen Bereich springt (z. B. -2147483648 binär 10000000000000000000000000000000). Dies führt bei einer ungenügend implementierten Konvertierung von Unixtime zu Datum und Uhrzeit ungewollt zu einem Wert vor Epoche (1. Januar 1970). Dieses Problem wird in der Softwareentwicklung als Zählerüberlauf (Counterwrap) bezeichnet. Im Vergleich zum Jahr-2000-Problem, welches im Wesentlichen beim Datumsstempel von Dateien auftrat, führt das Jahr-2038-Problem zu Fehlern bei elektronischen Transaktionen, die die Unixzeit als Zeitstempel verwenden. Ohne Gegenmaßnahmen könnten die wirtschaftlichen Auswirkungen verheerend sein, zumal im Banken- und Versicherungsumfeld Unix-Systeme neben Mainframes zur Standardausstattung gehören. Ein Beispiel für typische Jahr-2038-Fehler sind Transaktionen, deren Gültigkeit vom Zeitstempel des Ergebnisfeldes abgeleitet wird. Ist das Ergebnis nicht jünger als die Ausgangsdaten, so wird weiterhin auf ein gültiges Ergebnis gewartet oder die Transaktion irgendwann automatisch neu angestoßen. Am Stichtag des Jahr-2038-Problems werden allerdings sämtliche Ergebnisse den vermeintlichen Zeitstempel Dezember 1901 tragen, sind also immer älter als die Eingabedaten. Wartende Programme geraten so leicht in Endlosschleifen, was sich für den Endbenutzer in „abgestürzten“ Anwendungen äußert – z. B. ein Geldautomat, der endlos auf die elektronische Bestätigung der Kontenabbuchung wartet, bevor er Geld ausgibt.
- Problém roku 2038 (jinak známý jako "Unixový bug milénia", "Y2K38," "Y2K+38," nebo "Y2.038K" podle přirovnání k problému Y2K) může hypoteticky způsobit pád počítačových programů v roce 2038. Problém může nastat v Unixových nebo podobných datovacích systémech, které reprezentují systémový čas jako počet sekund od 00:00:00 1. ledna 1970. Tato reprezentace času se díky masové rozšířenosti programovacího jazyka C vyskytuje v programech pro většinu operačních systémů. Datový typ time_t je na většině 32-bitových systémech používán k ukládání vteřinového počítadla jako 32bitové celé číslo se znaménkem (32bit signed integer). Poslední čas, který takto může být zapsán, je úterý 19. ledna 2038 v 03:14:07. Čas v další sekundě „přeteče“ a bude vnitřně reprezentován jako záporné číslo, což způsobí pád programů, jelikož neuvidí takovéto datum jako 2038 ale spíše jako 1901.
- En informática, el problema del año 2038 podría causar que una parte del software fallara en ese año. El problema afecta a los programas que usen la representación del tiempo basada en el sistema POSIX, que se basa en contar el número de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00. Esta representación es un estándar de facto en los sistemas tipo Unix y también en los programas escritos para muchos otros sistemas operativos debido al gran alcance del lenguaje de programación C. En la mayoría de sistemas de 32 bits, el tipo de dato time_t usado para guardar el contador de segundos es un entero de 32 bits con signo, es decir, que puede representar un rango de números entre -2.147.483.648 y 2.147.483.647 (-2 y 2-1; 1 bit para el signo, y 31 para el valor absoluto), por lo que el último segundo representable con este formato será a las 03:14:07 UTC del 19 de enero de 2038, cuando el contador llegue a 2147483647. Un segundo después, el contador se desbordará, y saltará al valor -2.147.483.648, que causará el fallo de programas que interpretarán el tiempo como que están en 1901 ó 1970 (dependiendo de la implementación), en vez de 2038. A su vez, esto causaría cálculo y procesamiento incorrecto. No hay una forma sencilla de arreglar este problema para las combinaciones existentes de CPU/SO. Cambiar la definición de time_t para usar un tipo de 64 bits rompería la compatibilidad binaria para el software, almacenamiento de datos, y, por lo general, cualquier cosa que tenga algo que ver con la representación binaria del tiempo. Cambiar time_t a un entero de 32 bits sin signo afectaría a los programas que hacen cálculos con diferencias de tiempo. La mayoría de sistemas operativos para arquitecturas de 64 bits utilizan enteros de 64 bits para time_t. La migración a estos sistemas está todavía en proceso y se espera que se complete mucho antes de 2038. Usar un entero de 64 bits supondría el fin de estos problemas informáticos.
- Lyhenteellä Y2K38 tarkoitetaan Y2K-ongelmien kaltaista, 18. tammikuuta 2038 tapahtuvaa 32-bittisen kellon ympäripyörähtämistä. Unix-käyttöjärjestelmässä aikaa mitataan sekunteina nollahetkestä 1. tammikuuta 1970 kello 0.00.00 UTC. Tietokoneissa ja käyttöjärjestelmissä joissa käytetään ajan esittämiseen etumerkillistä 32-bittistä time_t-sekuntilaskuria tämä ajan esitystapa ei riitä ilmaisemaan 18. tammikuuta 2038 jälkeisiä aikoja. Monissa 64-bittisissä arkkitehtuureissa (esimerkiksi Linux/amd64) on siirrytty käyttämään 64-bittistä time_t:tä. Tilapäisratkaisuna on myös esitetty time_t:n muuttamista etumerkittömäksi, joka antaa siirrokseen lisäaikaa, mutta tällöin ei voida esittää ennen 1.1.1970 olevia ajankohtia. Ongelmana on myös, että jos time_t:n tyyppiä muutetaan, sitä käyttävät ohjelmat - käytännössä lähes kaikki ohjelmat - on pakko kääntää uudelleen. On kuitenkin erittäin todennäköistä, että 64-bittiset järjestelmät syrjäyttävät 32-bittiset järjestelmät kokonaan ennen kriittistä ajankohtaa, koska niihin siirtyminen alkoi laajasti palvelimissa 1990-luvulla ja jopa pöytäkoneissa 2000-luvun alussa. Ongelmaan on alettu törmätä jo varhemmin. Esimerkiksi kolmenkymmenen vuoden asuntolainan ottaminen vuonna 2008 voi paljastaa kyseisen ongelman.
- En informatique, le bogue de l'an 2038 est un problème similaire au bogue de l'an 2000 qui pourrait perturber le fonctionnement de certains ordinateurs aux alentours du 19 janvier 2038, et plus particulièrement le 19 janvier 2038 à 3 h 14 min 7 s, temps universel. Le problème concerne des logiciels qui utilisent la représentation POSIX du temps, dans lequel le temps est représenté comme un nombre de secondes depuis le 1 janvier 1970 à 0 heure. Sur les ordinateurs 32 bits, la plupart des systèmes d'exploitation concernés représentent ce nombre comme un nombre entier signé de 32 bits, ce qui limite le nombre de secondes à 2 - 1, soit 2 147 483 647 secondes (01111111 11111111 11111111 11111111 en binaire). Ce nombre maximum sera atteint le 19 janvier 2038 à 3 h 14 min 7 s. Dans la seconde suivante, la représentation du temps « bouclera » (10000000 00000000 00000000 00000000 en binaire) et représentera -2 147 483 648 en complément à deux, et ainsi, l'ordinateur affichera la date du 13 décembre 1901. Les logiciels concernés sont très nombreux car la norme POSIX, inspirée des systèmes UNIX, a été utilisée pour de nombreux programmes écrits en langage C pour de nombreux systèmes d'exploitation. Sur certains ordinateurs, la date limite est située en 2106 et non en 2038 car le temps y est représenté par un entier à 32 bits non signé (tout en restant conforme à la norme POSIX). Mais ces ordinateurs sont minoritaires. Le passage à 64 bits résout le problème définitivement, la date butoir se situant à l'an 292 277 026 596 après J.C. (Soit environ 21 fois l'âge de l'univers !), car les 64 bits permettent à l'ordinateur de pousser la limite à : 2 - 1 secondes. Mais malgré le succès croissant des ordinateurs à 64 bits, il est possible que de nombreux ordinateurs à 32 bits soient encore actifs en 2038, en particulier dans les systèmes embarqués. Il n'existe pas de correctif simple pour ce problème, dans la mesure où le format sur 32 bits est présent aussi dans de nombreux formats de fichiers actuels (par exemple le format ZIP). Un changement de représentation dans les ordinateurs rendrait donc inopérants les programmes qui exploitent l'actuelle équivalence entre la représentation interne et le format de fichiers.
- A számítástechnikában a 2038-as év problémája néhány szoftver meghibásodását okozhatja 2038-ban vagy akörül. A probléma a POSIX időábrázolást használó programokat érinti elsősorban, amely az időt az 1970. január 1. óta eltelt másodpercek számával ábrázolja. Ez az ábrázolási mód számít szabványnak a Unix típusú operációs rendszereknél, de érinti az egyéb operációs rendszerekre fejlesztett programok nagy részét, mivel a széleskörben használt C programozási nyelv is ezt az ábrázolási módot használja. A legtöbb 32-bites rendszerben, a time t adattípus, melyet a másodpercszámláló tárolására alkalmaznak, egy előjeles, 32-bites integer (egész szám) formátumú adat. A legkésőbbi időpont, amely még ábrázolható ebben a rendszerben a POSIX szabvány szerint 2038. január 19. , kedd, 03:14:07. Ezt követően az időpontok „körbefordulnak”, és belsőleg negatív számként jelennek meg, amely helyzet a programok meghibásodásához vezet. Mivel az időpontokat nem 2038-ra fogják tenni, hanem 1970-be vagy 1901-be, ez okból kifolyólag hibás számításokat és hibás döntéseket fog hozni a program. Erre a problémára nincs könnyű megoldás létező CPU/OS konfigurációk esetén. A time_t definíciójának megváltoztatása a 64 bites típus használatára megrendítheti a szoftver, a háttértároló, és általában minden bináris kompatibilitását, ami az idő bináris ábrázolását használja, de a time_t előjel nélküli 32 bites egész számra való állítása sem megoldás, mivel könnyen megzavarhatja az időkülönbséget számoló programokat. A legtöbb 64 bites architektúrát használó operációs rendszer már 64 bites egészben tárolja a time_t-t. Ezekre az architektúrákra való átállás már folyamatban van, és szakemberek számításai szerint 2038-ra be is fejeződik, viszont 32 bites kódok 100 milliói születnek meg még 2006-ban is, közülük nagyon sok beágyazott rendszerekben, melyeket aligha fognak mind lecserélni 2038-ig. Annak ellenére, hogy a számítástechnikában napjainkban 18-24 havonta vásárolnak alapjában véve új konfigurációkat, lehet, hogy a beépített számítógépek változatlanok maradnak az általuk irányított rendszerek egész életében. A 64 bites érték szerint egy újabb körbefordulás kb. 290 milliárd év múlva következik be, 292 277 026 596. december 4-én, vasárnap, UTC szerint 15:30:08-kor.
- Il Bug dell'anno 2038 è un noto bug informatico che ha ripercussioni su alcuni software nella gestione di date relative all'anno 2038 e successivi. Il problema riguarda programmi che usano la rappresentazione POSIX per calcolare il tempo: questa calcola la data del sistema a partire dal numero di secondi a partire dal 1º gennaio 1970. Questo tipo di sistema è lo standard per i sistemi Unix, e colpisce anche software per altri sistemi operativi che siano stati sviluppati in C. Sulla maggior parte dei sistemi a 32 bit il valore del dato time_t usato per questo calcolo è un numero intero a 32 bit di tipo signed. Usando questo sistema, la data più avanzata rappresentabile a partire dal 1/1/1970 sono le 03:14:07 UTC di martedì 19 gennaio 2038. Dopo questo momento, il contatore supererebbe il valore massimo, e verrebbe considerato come un numero negativo. I computer leggeranno la data non come 2038 ma come 1901, causando errori di calcolo. "Year 2038" è chiamato anche "Y2038", "Y2K38", o "Y2.038K" nel linguaggio specialistico.
- 2038年問題（にせんさんじゅうはちねんもんだい）は、2038年1月19日3時14分7秒（UTC）を過ぎると、コンピュータが誤動作する可能性があるとされる問題。
- År 2038-problemet (også kjent som «Unix Millennium bug», «Y2K38», «Y2K+38» eller «Y2.038K» som en analogi til År 2000-problemet) kan forårsake at noen dataprogram feiler før eller i 2038. Problemet omfatter Unix-lignende operativsystem, som representerer systemtiden som sekunder siden 1. januar 1970 klokken 00.00.00 .
- Problem roku 2038 – wada oprogramowania uniksowego, wymagającego informacji o bieżącym czasie, która może się ujawnić 19 stycznia 2038. Źródło problemu leży w sposobie zliczania czasu przez Unix – służy do tego 32-bitowa zmienna typu całkowitego ze znakiem (ang. signed integer) zawierająca liczbę sekund, które upłynęły od rozpoczęcia tzw. ery uniksa, czyli od 1 stycznia 1970, godz. 0:00. Maksymalna wartość wspomnianej zmiennej wynosi 2 147 483 647, co odpowiada godzinie 03:14:07 UTC, 19 stycznia 2038. W następnej sekundzie stan licznika sekund stanie się ujemny – nastąpi przeskok do najmniejszej wartości ujemnej (-2 147 483 648). Wyświetli się wtedy data 13 grudnia 1901 godz. 20:45:52. Może to spowodować poważne błędy w obliczaniu upływu czasu. Problem 2038 wydaje się o wiele groźniejszy od pluskwy milenijnej z 2000, a także trudniejszy do uniknięcia. Zapobiec mu może przejście na 64-bitową reprezentację czasu (typ time_t), dla której analogiczny problem pojawi się dopiero w roku 292 277 026 596, czyli za około 292 miliardy lat – dla porównania wiek Ziemi szacuje się na 4,5 miliarda lat. Zmiana taka jest już powoli dokonywana i należy się spodziewać, że zostanie zakończona przed rokiem 2038. Największym problemem wydaje się nie tyle zmiana samych systemów uniksowych, lecz zmiany potrzebne w oprogramowaniu, które z różnych względów polegało na 32-bitowym rozmiarze zmiennej zawierającej czas. Oprogramowanie takie spotykane jest na przykład w systemach bankowych i ubezpieczeniowych.
- O problema do ano 2038 é uma falha na representação de datas em computadores, que pode causar erros em alguns programas de computador no ano de 2038. O problema afeta os programas que utilizam a representação de tempo POSIX, em que a data é calculada através do número de segundos desde 1 de janeiro de 1970. Esta representação é padrão nos sistemas operacionais do tipo Unix e afeta a maioria dos sistemas, pois grande parte deste software foi desenvolvido na linguagem C. Na maioria dos sistemas de 32 bits, o tipo de dados time t, utilizado para armazenar esta contagem de segundos, é um inteiro de 32 bits do tipo signed (considera o sinal). O último registro de tempo que pode ser representado por este formato, seguindo o padrão POSIX, é 03:14:07 na terça-feira 19 de janeiro de 2038. Após este momento a data será representada por um número decimal negativo que, dependendo da implementação, corresponderá ao ano 1970 ou 1901. Este valor para a data corrente certamente resultará em erros de cálculo e de funcionamento na maior parte dos programas em execução pelo sistema.
- Файл:Year 2038 problem. gif Пример, показывающий сброс даты . Проблема 2038 года в вычислительной технике — ожидаемые сбои в программном обеспечении 19 января 2038 года. Данная проблема затрагивает программы и системы, в которых используется представление времени по стандарту POSIX, которое представляет собой количество секунд, прошедшее с 1 января 1970 года. Такое представление времени — это стандарт для Unix-подобных операционных систем (из-за повсеместного использования языка Си). На большинстве 32-битных систем используется тип данных time_t для хранения секунд в виде signed int (32-битного целого со знаком). Самая поздняя дата, которая может быть представлена таким форматом в стандарте POSIX — это 03:14:07, вторник, 19 января 2038 года по Всемирному времени (UTC). Более позднее время заставит такое поле данных стать отрицательным как бы закольцевав таким образом время (поскольку отрицательное число может быть воспринято программами как время в 1970 или 1901 году, в зависимости от реализации). В результате могут быть произведены ошибочные вычисления или результаты. Для проблемы 2038 года не существует простого решения для существующих комбинаций процессоров и операционных систем. Изменение определения типа time_t на 64 бита нарушит бинарную совместимость программ, существующих хранимых данных и всего другого использующего представление времени в бинарном виде. А приведение time_t в целое без знака может нарушить работу программ, которые вычисляют разницу во времени. На большинстве операционных систем для 64-битных архитектур уже используется 64-битное представление целого в time_t. Переход на такие архитектуры уже происходит, и некоторые ожидают, что он будет завершён к 2038 году. Тем не менее сотни тысяч 32-битных систем всё ещё вводятся в строй в 2009 году, в том числе и во встраиваемых системах. Вызывает сомнение, что они все будут заменены к 2038 году. Несмотря на то, что современные компьютерные системы могут модернизироваться раз в 18-24 месяцев, встроенные компьютеры могут действовать без модернизации весь срок, который работают системы, ими управляемые. Например, компьютеры управления процессами модели IBM 1800, выпуск которых был начат в 1965 году, всё ещё использовались на одной из атомных станций в Канаде в 2006 году. В дополнение к этому, 32-битный формат time_t также включён в спецификации форматов файлов, таких как повсеместно распространённый архивный формат ZIP. Формат файла может существовать в течение времени, за которое сменятся многие поколения компьютеров, а это означает, что Проблема 2038 останется актуальной. Введение 64-битного формата вносит новую дату «закольцевания» через примерно 290 миллиардов лет, в 15:30:08 UTC в воскресенье, 4 декабря 292 277 026 596 года.
- Y2K38 är beteckningen på ett stundande problem som väntar många datasystem år 2038. I likhet med Y2K-problemet rör det sig om att det utrymme som tillägnats tidmätningen i ex. operativsystemet inte längre räcker till. Ett vanligt sätt att hantera tid i operativsystem är att räkna antalet sekunder som passerat sedan den 1 januari 1970. Det är också tämligen vanligt att spara värdet i ett 32-bitars heltal med teckenbit, vilket då kan hantera högst 2147483647 sekunder. Klockan 03:14 den 19 januari år 2038 kommer detta heltal bli "fullt" och börja om på -2147483648 vilket motsvarar klockan 20:45 den 13 december 1901. En enkel åtgärd är att ändra programmet så att tiden istället lagras som ett 64-bitarstal. Problemet är att tidsfältet ofta förekommer i datastrukturer i till exempel filsystem, som inte går att ändra.
- 2038 yılı problemi, 2038 yılında bazı POSIX zaman gösterimini kullanan 32-bit sistemlerin çökmesine yol açacak bir yazılım hatasıdır. Hata, sistem zamanını 1 Ocak 1970 tarihinden beri saniye bazında hesaplayan ve 32-bitlik UNIX ve türevi sistemlerde 19 Ocak 2038 Salı günü saat 03:14:07'de sayacın başa dönmesiyle sistem tarihinin 13 Aralık 1901 20:45:52'yi göstermesiyle ortaya çıkacaktır. Son yıllarda bazı çözüm yöntemleri geliştirilse de hiçbiri basit ve uygulanabilir olamamıştır. Ancak 64 bitli sistemlere geçişin 2038 yılına kadar tamamlanacağı ve böylece hatanın kendiliğinden ortadan kalkacağı düşünülmektedir.
- Пробле́ма 2038 ро́ку в обчислювальній техніці — це очікувані збої в программному забезпеченні 19 січня 2038 року. Дана проблема зачіпає програми і системи, в яких використовується представлення часу за стандартом POSIX, який являє собою кількість секунд, що пройшли з 1 січня 1970 року. Таке представлення часу — стандарт для Unix-подобних операційних систем (через розповсюджене використання мови Сі). На більшості 32-бітових систем використовується тип даних time_t для зберігання секунд у вигляді signed int (32-бітового цілого із знаком). Найпізніша дата, яка може бути представлена таким форматом в стандарті POSIX - це 03:14:07, вівторок, 19 січня 2038 року за всесвітнім часом (UTC). Наступний момент часу час змусить таке поле даних прийняти від'ємне значення, що подібно до закільцювання часу. Оскільки негативне число може бути сприйнято програмами як час в 1970 або 1901 року, залежно від реалізації. В результаті можуть бути проведені помилкові обчислення або отримані некоректні результати. Для проблеми 2038 року не існує простого рішення для існуючих комбінацій процесорів і операційних систем. Розширення типу time_t до 64 біт порушить бінарну сумісність програм, існуючих даних, що зберігаються, і всього іншого, що використовує представлення часу в бінарному вигляді. А приведення time_t в ціле без знаку може порушити роботу програм, які обчислюють різницю в часі. Більшістю операційних систем для 64-бітової архітектури вже використовується 64-бітове уявлення цілого в time_t. Перехід на таку архітектуру вже відбувається, і за прогнозами, він буде завершений до 2038 року. Проте сотні тисяч 32-бітових систем все ще вводяться в лад в 2006 році, у тому числі і в вбудовуваних системах. Викликає сумнів, що вони всі будуть замінені до 2038 року. Не дивлячись на те, що середній період модернізації сучасних комп'ютерних систем складає 18-24 місяців, вбудовані комп'ютери можуть діяти без модернізації весь термін, який працюють системи, ними керовані. На додаток до цього, 32-бітовий формат time_t також включений в специфікації форматів файлів, таких як повсюдно поширений архівний формат ZIP. Формат файлу може існувати протягом часу, за який зміняться багато поколінь комп'ютерів, а це означає, що Проблема 2038 залишиться актуальною. Введення 64-бітового формату вносить нову дату «закільцьовування» через приблизно 290 мільярдів років, в 15:30:08 UTC в неділю, 4 грудня 292 277 026 596 року. Але ця проблема на даний момент не вважається терміновою.
- 在计算机应用上，2038年问题可能会导致某些软件在2038年无法正常工作。所有使用POSIX时间表示时间的程序都将受其影响，因为它们以自1970年1月1日经过的秒数（忽略闰秒）来表示时间。这种时间表示法在类Unix（Unix-like）操作系统上是一个标准，并会影响以其C编程语言开发给其他大部份操作系统使用的软件。在大部份的32位操作系统上，此「time_t」数据模式使用一个有正負號的32位元整數（signed int32）存储计算的秒数。依照此「time_t」标准，在此格式能被表示的最后时间是2038年1月19日03:14:07，星期二（UTC）。超过此一瞬间，时间将会被掩盖（wrap around）且在内部被表示为一个负数，并造成程序无法工作，因为它们无法将此时间识别为2038年，而可能会依個別實作而跳回1970年或1901年。错误的计算及动作可能因此产生。 目前并没有针对现有的CPU／操作系统搭配的简单解决方案。直接将POSIX时间更改为64位模式将会破坏对于软件、数据存储以及所有与二进制表示时间相关的部份的二进位兼容性。更改成无符号的32位整数则会影响许多与两时间之差相关的程序。 大部份64位操作系统已经把time_t這個系統變數改為64位寬。不過，其他現有架構的改動仍在進行中，不過預期「應該可以在2038年前完成」。然而，直到2006年，仍然有数以亿計的32位系统在運行中，特別是许多嵌入式系统。相对于一般电脑科技18至24个月的革命性更新，嵌入式系统可能直至使用寿命终结都不会改变。32位time_t的使用亦被编码于文件格式，例如众所周知的ZIP压缩格式。其能存在的时间远比受影响的机器长。 新的64位运算器可以记录至约2900亿年后的292,277,026,596年12月4日15:30:08，星期日（UTC）。
|
![[RDF Data]](/statics/sw-cube.png)
