UNIX-tid, har ni förberedd er?

[Icecap]

Som jag har läst det är UNIX-tid räknad i sekunder sedan 1970-01-01 00:00:00. Jag använder detta princip själv i många projekt då det ger en del fördelar.

Men då variabeln som tiden räknas i är en long (signed 32 bit) är det ju en bortre gräns innan datum blir fel. Den borde inträffa under början av år 2038 om jag inte räknar fel.

Själv har jag definierat "min" variabel till att vara unsigned men fortfarande en long. Redan detta ger runt 136 år istället för hälften varför man flyttar tiden till år 2106.

Men för att jag är som jag är använder jag 2010-01-01 00:00:00 som nollpunkt, då ger det problem först under år 2146. på det tidpunkt bör jag vara runt 184 år gammal och nog ha gått i pension så att jag inte behöver bekymra mig om detta.

Men är detta något som faktisk förväntas ge problem i verkligheten? Jag vet att många anser att "detta system lever inte till den tiden" men historien har ju visat att detta antagande kan vara våldsamt fel.

Jag vet att då "millennium-buggen" var på tapeten visade det sig att det faktisk i många administrativa system var år 1999 som var det verkliga problemet då just 1999-9-9 blev använd - och tolkat - som testdata.

[maDa]

Jag tror det kan bli problem 2038. Det är så oändligt med UNIX-baserade system som snurrar runtom överallt.

Vad som händer exakt är frågan, kommer det bli segmentation fault på massa processer, kommer det vara 1970-talet igen bara?

[AlterEgo]

Det kan säkert bli problem, men vi har drygt 20 år på oss att ändra det. Dom system som kan förväntas leva om 20 år och inte går att patcha går att skrota i lugn och ro och utveckla ersättare.

Men om man sticker huvudet i sanden och blundar för att man måste åtgärda, ja då blir det PROBLEM. Jag gör en del underhålls- och supportjobb på ett VB6-system som det började kodas på för 18 år sen och det är... inte så lätt i dagens WIndowsmiljö. Ja, jag har har föreslagit för dom att skrota systemet och göra ett nytt. Det var det bland det första jag gjorde när jag fick ta över supporten för två år sen...

[lillahuset]

Som jag fattat det är det enda som säger att time_t är en int32_t att det ofta är det. time_t är implementeringsbberoende.

[Nerre]

Vad jag förstått så använder många system redan idag 64 bitars time_t, problemen är främst databaser, filsystem och liknande som bara är designat med 32-bitars fält.

[sodjan]

Enbart slarvig design från början...
Här ett utskick från 1988 från några som tänkte till och tog ansvar.
Ett meddelande från Digitals HQ för support i USA. Speciellt sista
meningen ger trygghet...

Y10K and Y31K bugs

COMPONENT: SYSTEM TIME OP/SYS: VMS, Version 4.n
LAST TECHNICAL REVIEW: 06-APR-1988
SOURCE: Customer Support Center/Colorado Springs

The base time of Nov. 17, 1858 has since been used by TOPS-10, TOPS-20,
and VAX/VMS. Given this base date, the 100 nanosecond granularity
implemented within VAX/VMS, and the 63-bit absolute time representation (the
sign bit must be clear), VMS should have no trouble with time until:

31-JUL-31086 02:48:05.47

At this time, all clocks and time-keeping operations within VMS will
suddenly stop, as system time values go negative.
Note that all time display and manipulation routines within VMS allow
for only 4 digits within the 'YEAR' field. We expect this to be corrected
in a future release of VAX/VMS sometime prior to 31-DEC-9999.

Lite annat läsvärt:
https://tools.ietf.org/html/rfc2550
https://en.wikipedia.org/wiki/Year_2038_problem

[lillahuset]

Nerre: Jag tror inte det gäller alla filsystem. Tvärtom. NTFS får jag ibland känslan av att det är flyttal. Kopierar man runt en fil så kan den ändra tid med en sekund. Irriterande.
Det var väl VB som hade tiden som flyttal? Heltalsdelen innehöll dagar efter epoken och bråkdelen innehöll del av dygnet. Ganska intressant men slafsigt.

[Nerre]

Så funkar tid i Excel, allt tid anges i dagar eller om det är timmar.

[lillahuset]

Jag kollade ext4. Upplösning nanosekund, datum 1901-12-14 till 2514-04-25.

[TomasL]

Nerre: Jag tror inte det gäller alla filsystem. Tvärtom. NTFS får jag ibland känslan av att det är flyttal. Kopierar man runt en fil så kan den ändra tid med en sekund. Irriterande.
Det var väl VB som hade tiden som flyttal? Heltalsdelen innehöll dagar efter epoken och bråkdelen innehöll del av dygnet. Ganska intressant men slafsigt.

Nej NTFS är ett 64 bitars tal med 100 ns från 1601-01-01 00:00, dvs ett år efter det första storskottåret enligt den gregorianska kalendern.
Längden på tidsstämpeln lär nog räcka till ett tag.

Beträffande det där med tidsstämplar:

File properties with regards to the date and time stamps
•If you copy a file from C:\fat16 to C:\fat16\sub, it keeps the same modified date and time but it changes the created date and time to the current date and time.
•If you move a file from C:\fat16 to C:\fat16sub, it keeps the same modified date and time and keeps the same created date and time.
•If you copy a file from C:\fat16 to D:\NTFS, it keeps the same modified date and time but changes the created date and time to the current date and time.
•If you move a file from C:\fat16 to D:\NTFS, it keeps the same modified date and time and keeps the same created date and time.
•If you copy a file from D:\NTFS to D:\NTFS\SUB, it keeps the same modified date and time but changes the created date and time to the current date and time.
•If you move a file from D:\NTFS to D:\NTFS\SUB, it keeps the same modified date and time and keeps the same created date and time.
•In all examples, the modified date and time of a file does not change unless a property of the file has changed. The created date and time of the file changes depending on whether the file was copied or moved.

Folder properties with regards to the date and time stamps
•If you create two new folders on an NTFS partition called D:\NTFS1 and D:\NTFS2, both the created and modified date and time are the same.
•If you move the D:\NTFS2 folder into the D:\NTFS1 folder, creating D:\NTFS1\NTFS2, then:1.D:\NTFS1 - The created folder is the same and the modified stamp changes.
2.D:\NTFS1\NTFS2 - Both the created folder changes and the modified folder stay the same.
This behavior occurs because, even though you moved the folder, a new folder is seen as being created within the D:\NTFS1 folder by the Master File Table (MFT).
•If you copy the D:\NTFS2 folder into the D:\NTFS1 folder, creating the D:\NTFS1\NTFS2 folder, and the D:\NTFS2 folder still exists (after having copied it):1.D:\NTFS1 - The created folder is the same and the modified folder time and date stamp changes.
2.D:\NTFS2 - No changes occur because it is the original folder.
3.D:\NTFS1\NTFS2 - Both the created folder and the modified folder changes to the same stamp, which is that of the time of the move.
This behavior occurs because even though you copied the folder, the new folder is seen as being created by the MFT and is given a new created and modified time stamp.

Note: The design and behavior of the FAT file system is different with regards to the modified time stamp. On a FAT file system, the modified date of a folder does not change if the contents of the folder change. For example, if you have D:\FAT1 and D:\FAT2, and you copy or move D:\FAT2 into D:\FAT1, the created date and modified date of D:\FAT1 remains the same.

[mri]

"Kopierar man runt en fil så kan den ändra tid med en sekund. Irriterande."

Om jag inte minns fel har timetamp en upplösning på 2 sekunder i fat32, säkert samma med fat16. Detta ger antagligen fenomenet du beskriver om man kopierar från NTFS till FAT32.

[lillahuset]

Bra förklaring. De har säkert passerat ett USB-minne. Då kan jag grubbla över annat nu.

[Shimonu]

Hur kommer det sig att man valt en signed datatyp när ena halvan av talrymden inte går att utnyttja?

[lillahuset]

Förmodligen för att man vill använda -1 som resultat vid fel från time(). Och 2^31 sekunder är ju mer än 60 år.

[TomasL]

Hur kommer det sig att man valt en signed datatyp när ena halvan av talrymden inte går att utnyttja?

Tja du kanske vill kunna räkna tid innan "0" tiden så att säga, om det var en Unsigned, så kan du ju inte räkna på tider som inträffar innan den definierade start tiden.