<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<br class=""><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">esp-idf/components/fatfs/src.vfs_fat.c</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""><br class=""></span></font></div><div class=""><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">static int vfs_fat_stat(void* ctx, const char * path, struct stat * st)</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">{</span></font></div></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">...</span></font></div><div class=""><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class="">memset(st, 0, sizeof(*st));</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""> st->st_size = info.fsize;</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""> st->st_mode = get_stat_mode((info.fattrib & AM_DIR) != 0);</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""> fat_date_t fdate = { .as_int = info.fdate };</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""> fat_time_t ftime = { .as_int = info.ftime };</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""> struct tm tm = {</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""> .tm_mday = fdate.mday,</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""> .tm_mon = fdate.mon - 1, /* unlike tm_mday, tm_mon is zero-based */</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""> .tm_year = fdate.year + 80,</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""> .tm_sec = ftime.sec * 2,</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""> .tm_min = ftime.min,</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""> .tm_hour = ftime.hour</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""> };</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 14px;" class=""> st->st_mtime = mktime(&tm);</span></font></div></div></blockquote><div class=""><div><br class=""></div></div><div class=""><div>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.</div><div><br class=""></div><div>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:</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div>The functions ctime(), gmtime(), and localtime() all take as an argument a time value representing the time in seconds since the <b class="">Epoch</b> (00:00:00 <b class="">UTC</b>, January 1, 1970...</div></div></blockquote><div class=""><div><br class=""></div><div>But in vfs_ls, the st.st_mtime is already localtime, <b class="">not</b> UTC. </div><div><br class=""></div><div><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class=""><div class="moz-cite-prefix">I.e. file date is 10:14 → stat() applies -1 from "CET-1" → 09:14 → localtime() applies +2 → 11:14.</div></div></blockquote><br class=""></div><div>I think maybe different:</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div>file date is 10:14 local time → stat() returns 10:14 → localtime() applies +1 (DST accounted for) → 11:14.</div></div></blockquote><div class=""><div><br class=""></div><div>Maybe we should be using gmtime not localtime in vfs_ls? That won’t mess with DST or east/west shifts.</div><div><br class=""></div><div>Regards, Mark.</div><div><br class=""><blockquote type="cite" class=""><div class="">On 6 Jun 2018, at 4:59 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix">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.<br class="">
<br class="">
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.<br class="">
<br class="">
I.e. file date is 10:14 → stat() applies -1 from "CET-1" → 09:14 →
localtime() applies +2 → 11:14.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
Am 06.06.2018 um 10:43 schrieb Mark Webb-Johnson:<br class="">
</div>
<blockquote type="cite" cite="mid:98C7ACA8-37AB-49D1-9C14-2EC3BDFD536E@webb-johnson.net" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
My mac is showing Europe/Berlin as CET-1CEST,M3.5.0,M10.5.0/3.
That seems correct.
<div class=""><br class="">
</div>
<div class="">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).</div>
<div class=""><br class="">
</div>
<div class="">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?</div>
<div class=""><br class="">
</div>
<div class="">I read the FAT filesystems have no concept of time
zone, so timestamps could either be local or utc. Seems messy.</div>
<div class=""><br class="">
<div class="">Regards, Mark</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 6 Jun 2018, at 4:28 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="" moz-do-not-send="true">dexter@expeedo.de</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix">Just tested this entry from
the list:<br class="">
<pre class="" wrap="">"Europe/Berlin","CET-1CEST,M3.5.0,M10.5.0/3"</pre>
Same problem as with other public examples: local time
is correct, but file dates are offset 1 hour into the
future.<br class="">
<br class="">
<blockquote class=""><tt class=""># con set vehicle
timezone "CET-1CEST,M3.5.0,M10.5.0/3"</tt><br class="">
<tt class="">Parameter has been set.</tt><br class="">
<br class="">
<tt class=""># time stat</tt><br class="">
<tt class="">Time Zone: CET-1CEST;M3.5.0;M10.5.0/3</tt><br class="">
<tt class="">UTC Time: 2018-06-06 08:15:18 UTC</tt><br class="">
<tt class="">Local Time: 2018-06-06 10:15:18 CEST</tt><br class="">
<tt class="">Provider: ntp</tt><br class="">
<tt class="">PROVIDER STRATUM UPDATE
TIME</tt><br class="">
<tt class=""> gsm-nmea 2 12
Wed Jun 6 08:15:18 2018</tt><br class="">
<tt class="">*ntp 1 53
Wed Jun 6 08:15:17 2018</tt><br class="">
<br class="">
<tt class=""># vfs ls /sd</tt><br class="">
<tt class="">…</tt><br class="">
<span class=""><tt class=""> 5 06-Jun-2018 11:14
testdate</tt></span><br class="">
<span class=""></span></blockquote>
<span class=""><br class="">
Maybe this is a bug in the vfs.<br class="">
</span><br class="">
<span class=""><span class="">"<tt class="">CET-2,M3.5.0/02:00:00,M10.5.0/03:00:00</tt>"
works correctly now but I haven't tested if it
would adapt to winter time.<br class="">
</span><br class="">
</span>Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
Am 06.06.2018 um 08:56 schrieb Mark Webb-Johnson:<br class="">
</div>
<blockquote type="cite" cite="mid:2CA39356-2A66-416E-92D4-D308EDD87A03@webb-johnson.net" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
A topic on <a href="http://esp32.com/" class="" moz-do-not-send="true">esp32.com</a> brought up
this:
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none;
padding: 0px;" class="">
<div class=""><a href="https://github.com/nayarsystems/posix_tz_db" class="" moz-do-not-send="true">https://github.com/nayarsystems/posix_tz_db</a></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">I live in such a simple timezone, it is
hard for me to judge. Is this any use?</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
</div>
</blockquote>
<br class="">
<br class="">
<pre class="moz-signature" cols="144">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com" class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<!--'"--><br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<br class="">
<pre class="moz-signature" cols="144">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>