<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Mark,<br>
<br>
Ok, so I understand the memory limits. Didn't think it was that
bad, but not surprised either. Perhaps, could we accept <i>either</i>
the numeric or TZ formats? That said, the site we direct folks to
(PST8PDT) seems to have worked for me, at least for now. Maybe just
make it more obvious what to do? Or, get the time / timezone from
the vehicle? One should not need a man page to set the clock.<br>
<br>
Bottom line, we're making the setting of this normally trivial
parameter very complicated even for folks that are technically
capable. My preference would be to <i>allow</i> the more
complicated TZ syntax for those who want to delve into that level of
automation, but <i>accept</i> the simple +/-12.5 hr format by
default. I would argue that most everyone, technical or not,
understands the numeric format, and most, even among the technical,
do not understand TZ at the level necessary to construct their
string, and probably don't care to learn it. Reminds me of VCRs
blinking "12:00". <br>
<br>
Unless you're in a zone without DST, that is, in which case I would
argue you live in some sort of paradise. Or Arizona.<br>
<br>
Greg<br>
<br>
p.s. The HP LX Palmtops have a world-wide time zone database where
you entered the city you were near, and it would set the timezone
you were in. It also did date/time math, and other time-related
functions. You could override the DST dates with a simple text file
listing the date range for standard and daylight times, the offset
from GMT, and how far to move.<br>
<a class="moz-txt-link-freetext" href="http://www.palmtoppaper.com/ptphtml/26/pt260048.htm">http://www.palmtoppaper.com/ptphtml/26/pt260048.htm</a><br>
<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/HP_200LX">https://en.wikipedia.org/wiki/HP_200LX</a><br>
There is still an active user community around these magical
machines. I still have my 100LX, and still use it. It's outlived a
dozen PDA/cell phones and countless laptops and desktops.<br>
<br>
<br>
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:B7B41616-446A-48D9-8B29-D3477A52FED6@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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=""
moz-do-not-send="true">gregd2350@gmail.com</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=""> 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 class="" wrap="">On Tue, 22 May 2018, Greg D. wrote:
</pre>
<blockquote type="cite" class="">
<pre class="" wrap="">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 class="" wrap="">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" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">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=""
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>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
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>
</body>
</html>