[Ovmsdev] Default values and fields...

[Michael Balzer]

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 at expeedo.de <mailto:dexter at 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 <http://esp32.com/> brought up this:
>>>
>>>     https://github.com/nayarsystems/posix_tz_db
>>>
>>>
>>> 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 at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180606/1d756c2a/attachment.htm>