Starting in 2027, dates on files on UDF file systems generated by genisoimage will have incorrect time stamps. They will be set back by 16 hours.

UDF and iso9660 technically have date ranges that end with the year 9999. Therefore, the date and time should not be computed by calculating seconds from an epoch. UDF and iso9660 have no epoch. They have separate fields for years, months, ..., subseconds. By the way, genisoimage does not record subseconds, but that is a topic for a different bug ticket. It is not as urgent as this.

In addition, the iso9660 implementation of genisoimage is affected by the famous Y2038 bug. January 2038 will be no easy month in the world of computing, because nothing 32-bit is future-proof. This could also be handled by computing each time field separately. But this comes much later than the time bug that affects UDF, so it's less urgent.


How to reproduce:

~~~~
# cd /tmp
# touch -m -d 2027-01-01 test2027.txt
# touch -m -d 2028-01-01 test2028.txt
# genisoimage -udf -o tmp.img test202*
I: -input-charset not specified, using utf-8 (detected in locale settings)
Total translation table size: 0
Total rockridge attributes bytes: 0
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 0
419 extents written (0 MB)
# mkdir udftest
# mount tmp.img udftest
# ls --full-time  udftest
total 0
-r--r--r-- 1 root root 0 2027-01-01 00:00:00.000000000 +0100 test2027.txt
-r--r--r-- 1 root root 0 2027-12-31 08:00:00.000000000 +0100 test2028.txt
~~~~

Expected result:


~~~~
# ls --full-time  udftest
total 0
-r--r--r-- 1 root root 0 2027-01-01 00:00:00.000000000 +0100 test2027.txt
-r--r--r-- 1 root root 0 2028-01-01 00:00:00.000000000 +0100 test2028.txt
~~~~

Ideally, a file system implementation supports the entire date range of a file system and does not roll over at the end of the date range but just writes the highest possible date.

I just tested: Thomas Schmitt's xorrisofs (iso9660 only, not UDF) is not affected by Y2038. It uses the entire ISO9660 date range until the end of 2155. And dates after 2155 do not roll over to 1900, which is good. This is a future-proof design. So big applause to him!

Commands to reproduce:

~~~~
mkdir iso-test
year=2000
while [ $year -le 2200 ]; do touch -m -d iso-test/$year-01-01 $year; year=$(($year+1)); done
xorrisofs -o iso-test.iso iso-test
isoinfo -l -i iso-test.iso
~~~~

Excerpt of output:

~~~~
----------   0    0    0               0 Dec 31 2150 [     33 00]  2151.;1 
----------   0    0    0               0 Dec 31 2151 [     33 00]  2152.;1 
----------   0    0    0               0 Dec 31 2152 [     33 00]  2153.;1 
----------   0    0    0               0 Dec 31 2153 [     33 00]  2154.;1 
----------   0    0    0               0 Dec 31 2154 [     33 00]  2155.;1 
----------   0    0    0               0 Dec 31 2155 [     33 00]  2156.;1 
----------   0    0    0               0 Dec 31 2155 [     33 00]  2157.;1 
----------   0    0    0               0 Dec 31 2155 [     33 00]  2158.;1 
----------   0    0    0               0 Dec 31 2155 [     33 00]  2159.;1 
----------   0    0    0               0 Dec 31 2155 [     33 00]  2160.;1 
~~~~

(Indicated date is December 31 instead of January 1 due to time zones. This is normal.)

Extended attributes on iso9660 support up to year 9999 and 0.01 second time granularity, but that is not urgent for now. Source: https://www.ecma-international.org/wp-content/uploads/ECMA-119_4th_edition_june_2019.pdf