<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="">While I agree in general with the points you make, there are limitations on both the platform and the community.<div class=""><br class=""></div><div class="">Firstly, we don’t currently target this as an end-user device. We clearly say "Designed for technically experienced OVMS v2 users and v3 developers”. Main reason for this is to limit support calls, until firmware gets more mature, but also because it is relatively easy to make a developer kit when compared to an end-user product. We simply don’t have paid commercial support; everybody here are unpaid volunteers.</div><div class=""><br class=""></div><div class="">We could dumb-down the config setting for timezone, by not supporting DST auto-switch. A simple -12 .. 0 .. +12 dropbox selection. That is what a lot of consumer devices do. But, that just seems wrong if we have the capability. Does your HP 100LX handle DST auto-switch at all?</div><div class=""><br class=""></div><div class="">We can’t add nice country/city selection because of this:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">$ du -sh /usr/share/zoneinfo</div><div class="">5.5M<span class="Apple-tab-span" style="white-space:pre">        </span>/usr/share/zoneinfo</div></div></blockquote><div class=""><br class=""></div><div class="">That is from a Linux box. We don’t have 5.5MB of flash to store all the timezone settings. Maybe we could do some api in the cloud to look-up, but that is quite some work.</div><div class=""><br class=""></div><div class="">There are the iana rules files, which are smaller at 1.1MB, but still too big. They include all the historical info that we don’t need. I guess we could write some sort of parser and library to get it, but not at all easy.</div><div class=""><br class=""></div><div class="">So, the options are:</div><div class=""><ol class="MailOutline"><li class="">Dumb it down, and drop DST switching</li><li class="">Leave it as it is</li><li class="">Someone take it on as a sub-project to make it easier (just a simple country/city -> posix string mapping)</li></ol></div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""></div><div class="">P.S. As to the politics of timezones, I live in ‘HKT-8’ (POSIX string). No DST (since the 70’s). I have never really understood how DST can still exist in the modern age, and how the rules can be so complex. The cost of lost productivity must be horrendous.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 23 May 2018, at 7:36 AM, Greg D. <<a href="mailto:gregd2350@gmail.com" class="">gregd2350@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html;
      charset=ISO-8859-1" class="">
  
  <div text="#000000" bgcolor="#FFFFFF" class="">
    Hi Steve, all,<br class="">
    <br class="">
    This totally highlights the problem.  No offense intended to the
    developers (myself included), but we've not structured the product
    very well for "normal" folks who are somewhat technical, but have no
    inside knowledge of the product, prior versions, Linux, ESP-IDF,
    etc.  <br class="">
    <br class="">
    How was I to know what to put in the Timezone field?  Bear with me
    as I walk through my troubled mental process...  And please take
    this as me trying to be helpful.<br class="">
    <br class="">
    // Begin Rant<br class="">
    <br class="">
    So, I've seen configuration screens a bazillion times asking for
    timezone.  If there's not a pull-down, usually I would put in -7 for
    the US Pacific Daylight Time that I'm in right now, or -8 if on
    Standard Time, and make a mental note to change it next fall.  Not a
    big deal; there are a dozen "clocks" here at the house that need
    semi-yearly care.  What's one more?  Sometimes the config would be
    -8 with a checkbox for enabling DST.  More recent product config
    screens sometimes use cities, with Los Angeles being our "local"
    example.  That's been the set, so glancing at (but not truly
    understanding the implications of) the fine print on the
    configuration screen, I simply put in my -7 and moved on.  It's been
    that way for weeks, and I never noticed anything wrong until I saw
    the "GMT" reference on the Time at Boot status that I recently
    added.  Should have been "PDT".  Something's wrong.  Playing the
    ever-so-observant beta tester, I dig in...<br class="">
    <br class="">
    So, back to the config screen I went.  First, where was it?  I was
    doing a firmware update, but it's not there, and there's no General
    config tab.  Nothing labeled "Time".  Finally found it under
    Vehicle.  Really?  I see my -7 still sitting there, so it wasn't
    lost.  Finally I re-read the comment about a web link to "Example
    Timezone Strings", and think, huh, I guess there must be some other
    way to say "-7".  I click on the link, and scan down the table.  It
    says USA & Canada, Pacific Time, and PST8PDT.  Odd, but ok. 
    Copy & paste.  Hit Save.  Go back to the status page, and see
    PDT on the aforementioned boot status line.  Also see the upgrade
    was done yesterday afternoon, and realize that was 2am GMT, so I
    guess it checks out.  Annoying, but DONE.<br class="">
    <br class="">
    Now you tell me I'm <i class="">not done</i>, and that I really needed to
    click on the second link to the man page on glibc?  And <i class="">understand</i>
    it? Then research what the rules for DST computation are in my
    country, state, and so forth, to craft some sort of command lingo
    for the TZ engine?<br class="">
    <br class="">
    Reality check here.  My HP 100LX palmtop, manufactured in <b class=""><i class="">1992,</i></b>
    does a better job at handling this.  We've taken a simple task of
    entering a small, well known signed integer, and turned it into an
    exercise in POSIX programming and international politics.  This for
    a parameter that has little, if any, consequence on the daily
    operation of the product as I currently use it.<br class="">
    <br class="">
    // End Rant<br class="">
    <br class="">
    With a grateful acknowledgment to Michael for his awesome work on
    the Webserver UI, I think we should take a pass through the
    configuration steps with an eye towards making this as turn-key as
    possible.  I understand that he's made some significant changes to
    the UI since my module arrived (back on .003 code), so the
    improvements in initial config have not been reflected in what I am
    running now (since the config has already been set).  As I noted in
    my previous email, I will blow my module back to factory defaults
    and start over, looking for places where we might improve things.  <br class="">
    <br class="">
    I know that the V3 OVMS module is a VAST improvement over the prior
    versions, even without having experienced them myself.  But to reach
    a broader audience, we need to continually look to improve the setup
    / configuration experience, especially as we add new and even more
    powerful features.  <br class="">
    <br class="">
    Greg<br class="">
    <br class="">
    <br class="">
    <div class="moz-cite-prefix">Stephen Casner wrote:<br class="">
    </div>
    <blockquote type="cite" cite="mid:alpine.OSX.2.21.1805221204560.80508@auge.attlocal.net" class="">
      <pre wrap="" class="">On Tue, 22 May 2018, Greg D. wrote:

</pre>
      <blockquote type="cite" class="">
        <pre wrap="" class="">Oh, almost...  My timezone was also wrong.  It was set to -7 like I do
everywhere else, instead of PST8PDT.  Where did that come from?  My only
clue to this was that the new boot status display of time at last boot
said GMT instead of PDT.
</pre>
      </blockquote>
      <pre wrap="" class="">Because the ESP-IDF system does not have all the compiled-in timezone
code, we need to specify how to manage daylight saving time using the
long value for the TZ parameter.  So not even PST8PDT is sufficient,
you need "PST8PDT,M3.2.0/2,M11.1.0".

                                                        -- Steve
_______________________________________________
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="">
  </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>