The FAT directory structure seems to store the Y, M, D, H, M, S bitshifted into some words. It doesn’t store it as a julian date.

esp-idf/components/fatfs/src.vfs_fat.c

static int vfs_fat_stat(void* ctx, const char * path, struct stat * st)
{
...
memset(st, 0, sizeof(*st));
    st->st_size = info.fsize;
    st->st_mode = get_stat_mode((info.fattrib & AM_DIR) != 0);
    fat_date_t fdate = { .as_int = info.fdate };
    fat_time_t ftime = { .as_int = info.ftime };
    struct tm tm = {
        .tm_mday = fdate.mday,
        .tm_mon = fdate.mon - 1,    /* unlike tm_mday, tm_mon is zero-based */
        .tm_year = fdate.year + 80,
        .tm_sec = ftime.sec * 2,
        .tm_min = ftime.min,
        .tm_hour = ftime.hour
    };
    st->st_mtime = mktime(&tm);

The code in ff.c seems to just use localtime_r. For example, f_sync just uses XDIR_ModTime that uses get_fattime which is in diskio.c as using localtime_r. That seems correct and would match your observation that the timestamp is written correctly.

But given that FAT filestamps are in localtime already, presumably DST shifted by the localtime_r function, why are we calling localtime() again in the vfs_ls() function in ovms_vfs? The localtime function is defined as:

The functions ctime(), gmtime(), and localtime() all take as an argument a time value representing the time in seconds since the Epoch (00:00:00 UTC, January 1, 1970...

But in vfs_ls, the st.st_mtime is already localtime, not UTC. 

I.e. file date is 10:14 → stat() applies -1 from "CET-1" → 09:14 → localtime() applies +2 → 11:14.

I think maybe different:

file date is 10:14 local time → stat() returns 10:14 → localtime() applies +1 (DST accounted for) → 11:14.

Maybe we should be using gmtime not localtime in vfs_ls? That won’t mess with DST or east/west shifts.

Regards, Mark.

On 6 Jun 2018, at 4:59 PM, Michael Balzer <dexter@expeedo.de> wrote:

A PC shows correct file dates, and a file created on the PC is again shown incorrectly on the module, so it's clearly the VFS.

The stat() call seems to only apply the default time offset to get UTC from the file date. localtime() then applies the correct offset regarding summer time, ending up with an additional hour.

I.e. file date is 10:14 → stat() applies -1 from "CET-1" → 09:14 → localtime() applies +2 → 11:14.

Regards,
Michael


Am 06.06.2018 um 10:43 schrieb Mark Webb-Johnson:
My mac is showing Europe/Berlin as CET-1CEST,M3.5.0,M10.5.0/3. That seems correct.

I think that if local time is showing correct, then the posix time zone string is correct. It is now 8:34am UTC, and 10:34 CEST (Central European Summer Time).

Perhaps VFS is not handling DST correctly? Can you put the SD card in a PC and see what time is shown there? That would tell us if it is the VFS or our handling?

I read the FAT filesystems have no concept of time zone, so timestamps could either be local or utc. Seems messy.

Regards, Mark

On 6 Jun 2018, at 4:28 PM, Michael Balzer <dexter@expeedo.de> wrote:

Just tested this entry from the list:
"Europe/Berlin","CET-1CEST,M3.5.0,M10.5.0/3"
Same problem as with other public examples: local time is correct, but file dates are offset 1 hour into the future.

# con set vehicle timezone "CET-1CEST,M3.5.0,M10.5.0/3"
Parameter has been set.

# time stat
Time Zone:  CET-1CEST;M3.5.0;M10.5.0/3
UTC Time:   2018-06-06 08:15:18 UTC
Local Time: 2018-06-06 10:15:18 CEST
Provider:   ntp
PROVIDER             STRATUM  UPDATE TIME
 gsm-nmea                  2      12 Wed Jun  6 08:15:18 2018
*ntp                       1      53 Wed Jun  6 08:15:17 2018

# vfs ls /sd
…
5 06-Jun-2018 11:14 testdate

Maybe this is a bug in the vfs.

"CET-2,M3.5.0/02:00:00,M10.5.0/03:00:00" works correctly now but I haven't tested if it would adapt to winter time.

Regards,
Michael


Am 06.06.2018 um 08:56 schrieb Mark Webb-Johnson:
A topic on esp32.com brought up this:


The approach seems similar to what I spoke about before (scrape tzdata, although they scrape install zone files directly in /usr/share/zoneinfo). I’ve attached the csv output of that. 460 time zones, about 15KB code size. That is up-to-date with tzdata 2018d-1. Including a simple library wrapper, to (a) iterate over the zone names, and (b) return the posix string for a particular name, probably less than 20KB overhead.

I live in such a simple timezone, it is hard for me to judge. Is this any use?

Regards, Mark.



-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev



_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev



-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev