iriver H320 date recorded 1 hr off from date modified

[Oakbough]

Forgive me in advance if this is a really ridiculous concern:

I use iriver h320 w/ RB firmware for recording scientific data in remote areas. These devices are left for years and the data is downloaded every couple of weeks. I have been doing this for a year and a half and just encountered a new situation that I do not remember seeing before. During my last download I noticed that the "date modified" (of the file itself) is exactly an hour later than the name of the file (which is the time date stamp of the file). The time date stamp of each recording is critical to this research and my concern is that there may be a discrepancy in the actual time of the recording. I cannot imagine the device cashing the file for an hour before writing it to memory.  I thought it might be a daylight saving function but there does not seem to be any interface for it and the time difference does not seem to correspond correctly. Does anyone know if this is a valid concern or am I just overlooking something obvious.

Thanks for any assistance

Running version r12246M-070210

[Llorean]

You're using a ridiculously ancient version of Rockbox. There have been ten thousand revisions since that build. It is likely to be extremely difficult for someone to be able to provide you useful support for it.

Your best bet is to simply try to reproduce the circumstances it occurred and see what time the file starts recording, and what the timestamp is when it's done. Or review the code itself to see what exactly is going on.

[Oakbough]

Llorean, your probably right. It has been a while since the installation of the firmware and I noticed there has been many revisions. Unfortunately I am not code savvy so there is not much I can do with looking through it. I figured I will have to remedy the situation on site to find out what is happening, I thought in the mean time the community here might have some insight. Thanks for the quick reply

[Llorean]

I think your best bet is to actually run some tests and see what results you get in terms of time stamp vs filename. Was it many files this happened on or a single one? Was it always exactly 1 hour different, or did the difference vary at all? If so, how much?

[torne]

Are you in daylight savings?

The FAT filesystem stores timestamps in local time, not UTC. Rockbox does not automatically adjust the clock for daylight savings time, so when it is in effect, Rockbox will continue to write the timestamps out without the extra hour offset. Windows and other OSes will read these times as being the current, local time, so will interpret them as already including the daylight savings offset.

[Multiplex]

...I noticed that the "date modified" (of the file itself) is exactly an hour later than the name of the file (which is the time date stamp of the file).

I'm speculating wildly here as I've never used recording on my iRivers - but have some experience of similar recording requirements (PMR traffic as it happens), but it it a surprise? the event that triggered starting the recording file (and the naming of the file) will be at the start of the hour (and that event may be a new hour) and the last thing will be at the end of the hour, just before the system started a new file for the next hour, so it finished up the file and set the last modified time.

Of course I may by talking (typing) utter rubbish.  But as Llorean says a simple bench test should make things clear.