mirror of
https://github.com/SabreTools/MPF.git
synced 2026-02-10 21:30:29 +00:00
wrong exe date (PS2) #128
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @fuzz6001 on GitHub (Jul 10, 2019).
Originally assigned to: @mnadareski on GitHub.
!submissionInfo
The correct exe date is
2000-02-03.This is a time zone issue.
timestamp (from dic log)
@mnadareski commented on GitHub (Jul 30, 2019):
DICUI uses the UTC date as taken directly from the timestamp on the executable. I'm not changing this because UTC is proper even if actual Redump dates are the wild west of timezones.
@fuzz6001 commented on GitHub (Jul 30, 2019):
redump.org uses a local timestamp.
Isn't DICUI a tool for redump.org?
@mnadareski commented on GitHub (Jul 30, 2019):
No, DICUI is not a tool for Redump.org explicitly. Also, what good is a local timestamp if the timezone offset isn't stored as well? Even confining this to Redump alone, the discs and dumpers would span at least more than one timezone. Since the timezone information isn't stored in the least with regards to the EXE Date, then I opted to use the UTC date since, in nearly all modern web services, UTC date is considered the golden standard for the timestamp.
@fuzz6001 commented on GitHub (Jul 30, 2019):
I can only explain what I wrote in the previous post.
@Whovian9369 commented on GitHub (Jul 30, 2019):
I personally have to agree with @mnadareski here -- They're using a generally accepted timezone that's generally used for most time systems, and they refuse to stray away from the standard that many other people have agreed upon. At least in my view, it's definitely a lot smarter to do it under the standard, as it gives a more objective time as to when the game build was done, no matter what timezone the person is in.
I personally like your passion for this issue, but there's just some issues that you have to accept the given answer, and accept that it's not the answer that you would have personally chosen.
Besides, using your logic you're still incorrect, cuz the correct date is still 2000-02-02 -- At least, in my timezone and UTC.
@fuzz6001 commented on GitHub (Jul 30, 2019):
It's not my logic.
It's redump.org logic.
@Whovian9369 commented on GitHub (Jul 30, 2019):
Then it's time to talk to redump.org's mods to try and get that changed to use the standard UTC. Thanks for the good idea to talk to the mods!
@fuzz6001 commented on GitHub (Jul 30, 2019):
http://redump.org/disc/4496/
@mnadareski commented on GitHub (Jul 30, 2019):
As stated previously, there is no standard for Redump at the moment regarding this. This tool outputs something that is consistent across all regions and will produce proper outputs as any good tool should. If you want to make your own build to pull the date from DIC's logs, go for it. I'm not stopping you and this is an open source project, but DICUI itself will stay using UTC for its automatic output.
@fuzz6001 commented on GitHub (Jul 30, 2019):
I see. I do not use this tool for redump.org.
@ghost commented on GitHub (Jul 30, 2019):
If computers use Unix Time Stamp, then we shall too. It has nothing to do with a time system that is not the standard for the platform. It was the standard when they were created and that does not change because the world moves on. That would be inaccurate.