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