541
clrmame Discussion / Re: Dates don't match
« on: 11 January 2021, 08:34 »
Actually the latest nightly works like this:
- Rebuilding to zip with recompress enable, creates the right date from the dat
- Rebuilding to a decompressed file on NTFS, rar and 7z creates a file where the offset to UTC is included..
- Scanning/fixing a zipfile works fine
- Scanning/fixing decompressed/rar/7z will create a fixing loop due to the UTC offset
I love it...*sigh*...working on the decompressed/7z/rar time handling.....till then..use zip
ok...tried to handle decompressed files now as UTC based (which also is the reason for 7z/rar)
https://mamedev.emulab.it/clrmamepro/binaries/cmpro20210111.7z
This should fix the upper stuff...again I find it hard to say what is right if we talk about preservation...and especially if you look at it....you see the dat with 00:00:00 and you look at the archive or the file and you see an offset based value......something to think about when I got more time...but at least you shouldn't run into scan time fixing loops.
- Rebuilding to zip with recompress enable, creates the right date from the dat
- Rebuilding to a decompressed file on NTFS, rar and 7z creates a file where the offset to UTC is included..
- Scanning/fixing a zipfile works fine
- Scanning/fixing decompressed/rar/7z will create a fixing loop due to the UTC offset
I love it...*sigh*...working on the decompressed/7z/rar time handling.....till then..use zip
ok...tried to handle decompressed files now as UTC based (which also is the reason for 7z/rar)
https://mamedev.emulab.it/clrmamepro/binaries/cmpro20210111.7z
This should fix the upper stuff...again I find it hard to say what is right if we talk about preservation...and especially if you look at it....you see the dat with 00:00:00 and you look at the archive or the file and you see an offset based value......something to think about when I got more time...but at least you shouldn't run into scan time fixing loops.