kort efter Y2K lavede vi vittigheder om ” næste op, Y2038!”men dengang følte det en evighed i fremtiden og sandsynligvis vil være en andens problem. Nu hvor vi er halvvejs der, og vi allerede har nået det punkt, hvor y2038-problemer kan forårsage programfejl, er det en god mulighed for at begynde at planlægge Y2038. For eksempel kan programmel allerede have problemer med at arbejde med 20-årige certifikatlevetider eller 20-årige realkreditlån, og hyppigheden af disse problemer vil kun stige, når vi kommer tættere på Y2038. Hos Akamai kører vi allerede strategisk målrettet intern planlægning og test for Y2038, og det forekommer sandsynligt, at omfanget af dette arbejde vil fortsætte med at vokse i løbet af de næste 19 år, da denne vigtige indsats øges i Haster.

meget lidt gik galt på januar 1, 2000 for os (kort af nogle Javascript på en Akamai marketing site viser “19100” som den aktuelle dato!), men en ting, der bliver savnet, er, at den begrænsede globale indvirkning den aften skyldtes to faktorer: 1) mængden af avanceret forberedelse, der blev gjort; 2) mange “Y2K problemer” faktisk opstod år i forvejen snarere end under roll-over selv. Spring sekunder er på nogle måder skræmmende end datoformatproblemer, idet de er sværere at teste for, og meget mindre af virkningen sker på forhånd. Der er en risiko for, at manglen på virkninger af Y2K kan få organisationer og teknologer til at forberede sig på Y2038. Det er også sværere at forklare “Y2038” for lægfolk end Y2K, hvilket potentielt gør det sværere at prioritere og fokusere avanceret arbejde. Det store antal indlejrede tingenes internet (IoT) enheder bliver allestedsnærværende i vores miljø gør også den sandsynlige risiko og potentielle indvirkning betydeligt højere for Y2038 end det var for Y2K.

vores første erfaring med y2038 planlægning (udover at se chok fra folk ved at høre bekymringer bliver rejst, at ved første lyd 19 år væk) er, at en trinvis og fokuseret tilgang er nødvendig på dette stadium. Meget mere involverede og omfattende programmer vil helt sikkert være nødvendige nogle år ned ad vejen. I denne indledende fase, nogle områder at fokusere på omfatter: 1) programmer, der beskæftiger sig med fremtidige tider og datoer; 2) on-the-tråd besked og filformater; 3) enheder med lang implementeret levetid, og deres afhængigheder. Når vi kommer tættere på, bliver det naturligvis kritisk at begynde at fokusere på bredere sæt systemer, herunder at sikre, at de kan håndtere at krydse y2038-overgangen sikkert.

programmer, der beskæftiger sig med fremtidige datoer

måske er det vigtigste område at fokusere på i første omgang programmer, der beskæftiger sig med datoer i fremtiden, f.eks. til håndtering af 509 certifikater eller til finansiel planlægning. Der er mange dato-og tidsformatrepræsentationer, som ikke alle har et y2038-problem. For eksempel har programmer, der har brug for at håndtere tider i de sidste århundreder (længe før 1970), ofte valgt forskellige dato-og tidsrepræsentationer. 509 certifikater (som brugt til HTTPS) og certifikatmyndigheder (CAs) har vi fundet adskillige programmelproblemer i laboratoriet, der begynder at opstå med certifikater og CAs, der udløber forbi Y2038.

OpenSSL har især flere tidsformater, hvor ASN1_UTCTIME har en grænse i Y2049 (et særskilt problem at planlægge for fra Y2038), så brug asn1_time-funktionerne giver kompatibilitet med alle tidsintervaller. Konvertering af times out fra et bibliotek som OpenSSL out til 32-bit time_t er et ekstra område, der sandsynligvis har problemer.

i mange af disse tilfælde har det været muligt at løse problemerne ved blot at portere og kompilere ældre programmer til 64-bit arkitekturer (f.eks. at flytte fra et 32-bit heltal time_t til en 64-bit time_t). I andre tilfælde har der været behov for mere omfattende ændringer, især når tiderne bliver kastet i heltal til matematik, eller når meddelelsestrådformater bliver involveret, eller når værdier gemmes i databaser. Ved test og fastsættelse af støtte til 20-årige CAs er en ting, der dukkede op, at nedstrøms afhængigheder også kommer i spil. For eksempel, hvis en dato 20 år i fremtiden bliver ført ind i et logsystem eller overvågningssystem, og hvis disse igen føder til alarmeringssystemer eller rapporteringsdatabaser eller klargøringssystemer, så har de muligvis også alle brug for rettelser.

on-the-tråd besked og filformater

som nævnt ovenfor, når 32-bit tidsstempler sættes i meddelelser, databaser eller filformater virkningen kan strække sig langt ud over et bestemt system. Dette er også systemer med eksterne afhængigheder, hvor mere avanceret planlægning ofte er nødvendig, da interaktioner krydser systemgrænser. For disse samlinger af interoperative systemer kan det være nødvendigt at frigive ændringer i en bestemt rækkefølge, og bagudkompatibilitet kommer ofte i spil. Desuden, hvis der enten er formelt eller uformelt standardiserede protokoller, der bruger 32-bit epoke tidsstempelværdier i meddelelser, kan enhver migration eller rettelse baseres på fastsættelse af standarden. Som sådan bliver disse vigtige at bekymre sig om som med en afhængighedskæde som:

1. Opdater protokol / standarder til understøttelse af tidsstempler efter Y2038.
2. Implementer understøttelse af opdateret standard i programbiblioteker.
3. få ny version af biblioteker indarbejdet i programpakker.
4. få programpakker inkluderet i nyt forsendelsesprodukt.

så hvis hver af disse tager et par år, og forsendelsesproduktet har en lang levetid, kan de lange leveringstider her allerede være et problem.

enheder med lang implementeret levetid og deres afhængigheder

et andet område at begynde at fokusere på tidligt er enheder med lang implementeringstid. Som netop nævnt er det også vigtigt at følge de eksterne afhængigheder, som disse enheder har. Indlejrede enheder forsendelse med 32-bit udstyr kan heller ikke have en nem løsning af “bare kompilere for en 64-bit time_t” via en programopdatering, eller at gøre det kunne have uacceptabel ydeevne indvirkning.

tilsluttede biler og andre IoT-enheder er sandsynligvis et område med særlig bekymring, men jeg er sikker på, at der er mange andre lignende typer enheder og applikationer. I betragtning af de nuværende tendenser er det sandsynligt, at over 10% af de biler, der sælges i dag, stadig vil fungere i Y2038, og med stigninger i køretøjets alder og antal køretøjer på vejen kan dette være endnu højere. Hvis det tager et par år for skibsbiler at være generelt y2038-kompatible, med den nuværende (og stigende) fordeling af motorkøretøjsalder, kan vi ende med en betydelig del af biler med potentiale til at have alvorlige problemer i nitten år. Det samme mønster findes sandsynligvis også i nogle andre brancher, såsom inden for forbrugerelektronik (såsom hjemmespilkonsoller og smart-TV), hvor enheder muligvis sendes med 20+ års CA-certifikater forudinstalleret.

enheder med lang implementeret levetid kan kræve mere omfattende test af både enheden og dens afhængigheder, såsom test af, at operativsystemet og programmet fortsætter med at fungere korrekt før, under og efter y2038-overgangspunktet.

Godt Nytår!

y2038-udgaven er i en lignende kategori som IPv6: det er en multi-årti udrulning, der i det generelle tilfælde er vigtig, men endnu ikke presserende (pr. Fra dette perspektiv er nu lige så god tid som nogen til at begynde at planlægge, triaging og teste, før det bliver presserende (eller for sent). Fokuser først på programmer, der beskæftiger sig med fremtidige datoer, on-the-tråd besked og filformater, og enheder med lang implementeret levetid. Brug derefter erfaringerne fra det oprindelige fokus til at opbygge et mere omfattende program i de kommende år. Uanset hvad skal du indstille en minimumslinje og begynde at sikre dig, at nye programmer, systemer, protokoller og produkter, du bygger og implementerer, ikke introducerer y2038-problemer og markerer bekymringer, når du ser 32-bit tidsstempler-siden-den unikke-epoke inkluderet i nye designs.Erik Nygren er en kollega og chefarkitekt i Akamais Platform Engineering organisation. Han fejrer sit 20-års jubilæum på Akamai i Juni.

tak til flere mennesker på Akamai for deres bidrag til denne artikel.

mens der er taget forholdsregler ved udarbejdelsen af dette dokument, Akamai Technologies, Inc. påtager sig intet ansvar for fejl, udeladelser eller for skader som følge af brugen af oplysningerne heri. Oplysningerne heri kan ændres uden varsel. Akamai og Akamai-logoet er registrerede varemærker eller servicemærker i USA (Reg. U. S. Pat. & Tm. Ved). Udgivet 10. Januar 2019.