Codechange: Replace platform-specific calls with std::filesystem::last_write_time.

[PeterN]

Motivation / Problem

fios.cpp has Windows and Unix specific code to determine the modification date of a file.

Description

Use std::filesystem::last_write_time instead. The modification time doesn't ever seem to be displayed, it is only used in sorting, so the values don't need to match their previous values.

Limitations

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

• The bug fix is important enough to be backported? (label: 'backport requested')
• This PR touches english.txt or translations? Check the guidelines
• This PR affects the save game format? (label 'savegame upgrade')
• This PR affects the GS/AI API? (label 'needs review: Script API')
  • ai_changelog.hpp, game_changelog.hpp need updating.
  • The compatibility wrappers (compat_*.nut) need updating.
• This PR affects the NewGRF API? (label 'needs review: NewGRF')
  • newgrf_debug_data.h may need updating.
  • PR must be added to API tracker

[glx22]

Master:

This PR:

The order is messed up.

In file explorer:

[PeterN]

So this call just doesn't work on Windows?

Using milliseconds causes the uint64_t - uint64_t operation which is then placed into a int to behave differently. Worked around by using seconds instead of milliseconds.

[rubidium42]

Using milliseconds causes the uint64_t - uint64_t operation which is then placed into a int to behave differently. Worked around by using seconds instead of milliseconds.

How is converting to seconds make it not have the same issues? Okay, maybe after 49 thousand instead of 49 days, but still not a completely insane timescale to think about. Especially when the solution is relatively trivial.

Before the epoch there are issues because we use a uint64_t instead of just int64_t which my 64 bit Linux uses. So the type of mtime should probably be changed to int64_t to prevent any issues with pre-(undefined-)epoch times.
Then milliseconds or seconds will be just fine if you use ClampTo<int32_t> like we do when comparing for example engine costs.

[rubidium42]

Works for me with saves from 1969, 1970, 1972, today, 2038, 2039 and 2300.