-
Notifications
You must be signed in to change notification settings - Fork 7.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SD_MMC not using daylight saving time on file times ??? #6786
Comments
@P-R-O-C-H-Y, PTAL. Thanks. |
This sounds like a localization issue. How are you setting your time? Why do you subtract 3600 from the time? |
I have fetched the correct internet time, and printed it -- here is the code and the serial monitor. So the ctime and localtime give me correct time, but when I create the file it shows correct time after I move the sd card to windows computer, but when I access it from getLastWrite(), then it it 1 hour too high. I am MST7MDT,M3.2.0,M11.1.0, so utc-7 in winter, and utc-6 current, and utc is about 21:09 and I get 15:09 about 3:09 pm which is correct, but the file desklens2.999.txt and desklens2.001.avi created just after the reboot (3:10 by then), need that 3600 second adjustment to show the correct time, so getLastWrite() is giving me time of utc-5 or 4:09 if I hadn't subtracted 3600 seconds.
|
Here is a bit of code to demonstrate the problem. It sets the time to MST7MDT,M3.2.0,M11.1.0, in
... and the creates a file, closes it, opens it and checks the last write.
Over on Windows, the sd card shows the correct time for all the files. If you switch timezone to GMT -- no daylight savings -- then it works correctly (other than the 1970 case which shows 1980). (screeshots at the bottom)
|
Can you please test to isolate whether this is a file issue or locale issue. The following code works correctly for me. Post a variation of it that compiles and shows your issue.
|
I'll try that this evening, but I am using sd_mmc rather than Littlefs - might be an issue??? |
Please post a variation of it that compiles and shows your issue. |
I think it must be the code for getLastWrite in sd_mmc. sd_mmc seems to get the correct system time when the file is created, but it doesn't handle the daylight savings time correctly when reading the file time. Thanks for your interest in the topic. A little interesting that the time is not 3600 seconds wrong, but 3599 seconds wrong.
|
Funky. That's upstream in fatfs. Reproducible with FFat as well. I've opened an issue in ESP-IDF. |
mktime function uses tm_isdst member as an indicator whether the time stamp is expected to be in daylight saving time (1) or not (0). FAT filesystem uses local time as mtime, so no information about DST is available from the filesystem. According to mktime documentation, tm_isdst can be set to -1, in which case the C library will try to determine if DST was or wasn't in effect at that time, and will set UTC time accordingly. Note that the conversion from UTC to local time and then back to UTC (time_t -> localtime_r -> FAT timestamp -> mktime -> time_t) does not always recover the same UTC time. In particular, the local time in the hour before DST comes into effect can be interpreted as "before DST" or "after DST", which would correspond to different UTC values. In this case which option the C library chooses is undefined. Closes #9039 Originally reported in espressif/arduino-esp32#6786
mktime function uses tm_isdst member as an indicator whether the time stamp is expected to be in daylight saving time (1) or not (0). FAT filesystem uses local time as mtime, so no information about DST is available from the filesystem. According to mktime documentation, tm_isdst can be set to -1, in which case the C library will try to determine if DST was or wasn't in effect at that time, and will set UTC time accordingly. Note that the conversion from UTC to local time and then back to UTC (time_t -> localtime_r -> FAT timestamp -> mktime -> time_t) does not always recover the same UTC time. In particular, the local time in the hour before DST comes into effect can be interpreted as "before DST" or "after DST", which would correspond to different UTC values. In this case which option the C library chooses is undefined. Closes #9039 Originally reported in espressif/arduino-esp32#6786
Hi @jameszah, can you retest it with Arduino-esp32 2.0.4 version? Thanks I got this output, which looks correct. Tested with last sketch you posted.
|
As it was mentioned in esp-idf issue, FATFS keeps time at 2-second precision. So there can be this 0-2 seconds difference 😄. |
mktime function uses tm_isdst member as an indicator whether the time stamp is expected to be in daylight saving time (1) or not (0). FAT filesystem uses local time as mtime, so no information about DST is available from the filesystem. According to mktime documentation, tm_isdst can be set to -1, in which case the C library will try to determine if DST was or wasn't in effect at that time, and will set UTC time accordingly. Note that the conversion from UTC to local time and then back to UTC (time_t -> localtime_r -> FAT timestamp -> mktime -> time_t) does not always recover the same UTC time. In particular, the local time in the hour before DST comes into effect can be interpreted as "before DST" or "after DST", which would correspond to different UTC values. In this case which option the C library chooses is undefined. Closes #9039 Originally reported in espressif/arduino-esp32#6786
Board
ESP32-S on AI-Thinker ESP32-CAM
Device Description
normal esp32-cam with camera and wifi turned on
Hardware Configuration
no
Version
v2.0.3
IDE Name
Arduino ide 1.8.19
Operating System
Windows 10
Flash frequency
80MHz
PSRAM enabled
yes
Upload speed
115200
Description
After correctly fetching the time over wifi, and creating a file on the sd card, the file date from file.getLastWrite() shows 1 hour ahead of time. When the sd is removed and put in a computer the date shows correct - 1 hour behind the date that getLastWrite shows.
This worked before the time-change on 2.02. Since the time changed in March, and the 2.03 just arrived last week or so, ... I don't know if both factors are relevant.
Would it be in the FS library?
pictures show a esp32 hosted file directory, and the same files on windows 10 "date modified".
Sketch
Debug Message
Other Steps to Reproduce
none
I have checked existing issues, online documentation and the Troubleshooting Guide
The text was updated successfully, but these errors were encountered: