[ Enhancement ] Add support for TimeZones in FS operations

[YourWishes]

Hello, please refer to this ongoing discussion; https://github.com/DS-Homebrew/TWiLightMenu/issues/2360

Currently TWiLightMenu is using libfat for their FS operations, but are considering replacing with libnds FS operations. A current bug on the DSi firmware is a lack of TimeZone, and FS operations are assuming the time is set to UTC+0. This causes file timestamps to drift by the value of whatever the timezone the user is in, e.g. if I am in UTC+10:00 then when I save a file it will appear to have been saved 10 hours in the future from the actual time it was saved.

Just opening the conversation at this point, perhaps either extending rtcTimeAndDate struct or creating a new rtcTimeAndDateWithTimeZone struct could work instead. Alternatively adding some FILE operations that can take consideration of timezone(s), as I think this is one of the only affected areas.

Previously https://github.com/blocksds/libnds/issues/87

[asiekierka]

Where would this timezone information be read from, and how would this be standardized across all homebrew?

I believe this is a bad idea - having 20% of homebrew write timestamps with UTC+10 and 80% (which will never, ever be updated!) with UTC+0 sounds intuitively worse than 100% writing timestamps with UTC+0.

[YourWishes]

I'm not entirely sure what is possible for the libnds system itself, whether this has to be done per-homebrew implementation, or if there is some means to store this within the DS firmare or BIOS somewhere.

Ideally it would just be that any homebrew consuming the libnds file.h api would receive the benefit without having to consider implementation, and the existing rtcTimeAndDate methods would match what is already being returned in its state today.

Additional methods for setting/getting timezone information would be added for those homebrew that wish to consume it, and store this in some common area (firmware/bios?). If this isn't how it could work let me know some alternatives that could be considered.

[asiekierka]

Ideally it would just be that any homebrew consuming the libnds file.h api would receive the benefit without having to consider implementation

So only BlocksDS homebrew made after a certain date; not homebrew made with devkitARM (unless you convince them to also adopt it), not homebrew made with older versions of BlocksDS or devkitARM, and not official DSi software. That's my concern here - it will lead to confusion between the two groups of software.

I personally strongly believe it's better to keep the status quo, in this specific case. The added RAM usage burden and incompatibility is not worth the benefit of slightly more accurate timestamps.

[YourWishes]

OK sounds like it may be a non-starter, will take back to the TWiLight guys and see how best to tackle from that side. Main affected thing is NDS save files, so perhaps an extended file.h API with manual timezone as an argument would be best, but will wait and see what I can find on their side.

[AntonioND]

I'm not so worried about the lack of compatibility, I'm mostly worried about getting the timezone information to begin with. On DSi I guess you could get the firmware settings and guess the timezone from the country (but that's not reliable, the US has 4 timezones, Spain has 2 timezones, etc). And well, this would only work on DSi, not DS.

And I'm not sure about a manual argument for DS homebrew loaders. There are 3 protocols that DS homebrew loaders can support:

• DLDI: Most loaders do DLDI patching, this is very well supported in general.
• argv[]: This isn't well supported at all. A few flashcards support this right away, but it's a lot less common than DLDI.
• Reset to loader routine: This is barely ever supported.

I just think that a protocol to set the time zone simply wouldn't be adopted.

[AntonioND]

I'm going to close this, I think it's just too impractical for the reasons mentioned above by me and @asiekierka.