Bill, thanks for the feedback. Time stuff in general makes my head hurt! I only did a tiny bit of Unix and it was so long ago that it no longer counts. So for better or worse, it wasn't an influence when writing this library XD
tracking time gets pretty simple once you leave the human form of time representation behind
and buy into the epoch concept which is the only real way to tell
when something actually happened since locality is removed from the equation.
i.e. track time in a simpler form based on a epoch and then convert it to what humans like to see
only when the human wants to know what time it is.
epochs also make comparing date/times and calculating deltas trivial
and allow you to compare times from different localities without having to know
the localities.
Consider how complicated things get when trying to figure out exactly how long
ago something happened, if someone tells you it occured at exactly at: YYYY-MM-DD-HH:MM:SS
In order to know how much time has passed, you have to know the two timezones.
- yours, and his and then do lots of complicated math with many exceptions to get to
the elapsed time.
This is why the arilines don't use local times to track time. They all use "ZULU" time which
is GMT. http://wwp.greenwichmeantime.com/info/zulu.htm
One thing I do wonder about is if humanity is ever wiped out,
would future aliens go crazy trying to figure out
the significance of 1970-01-01-00:00 as much as we wonder about the significance of
they mayan 2012-12-21 ?
If I were to call localtime on a Unix machine, whose local time would I get? Whatever zone the machine was set for?
Yes, but it can be overridden by the users TZ environment variable
which gets pulled into in the current running process doing the locatltime() call.
And the beauty of that is that it allows things like networking and remote processes
to have known consistencies with time even when the machines are in different localities
using different timezones.
BTW, Windows NT also uses epoch based time, but they chose a different epoch.
(I was reading about localtime here, looks like a nice site, don't think I'd come across it before.)
I'm more use to the C version as C++ was invented yet when I was doing lots of kernel work back in the early 80s'.
On thing that might be useful for unix types,
would be to add localTime() & localTime_r() functions to the TimeZone object
that returns a pointer to a filled in struct TimeElements
Then uses could do something like:
utc = now();
myTZ.localTime_r(&utc, &tm);
and then have the full TimeElements available.
This could be an addition to the existing code as you
you wouldn't have to change the current code to add it.
In order to support localTime() you would have to have to reserve
the space for the TimeElements structure, wherease for localTime_r
would simply write over the users variable.
But they are pretty small easy to write functions that can simply
use the existing Time and Timezone functions to fill in the TimeElements
structure.
The only real bummer is that Michael changed some of the tm elements
to be 1 based vs 0 based when he created his Arduino Time library.
And that can't be change now without likely breaking lots of existing code.
--- bill