The Time library was recently updated. Teensyduino 1.13 still has the old copy. The latest code is here:
However, there's 2 bugs. I'm working on them. #1: the TIME_T is in UTC. I'm planning to change the number Arduino passes to the compiler to localtime. #2: mk20dx128.c isn't recompiled every time you use upload or verify, so the time defaults to the last time that particular file was compiled.
Of course, you can call rtc_set() or Teensy3Clock.set() to set the time correctly. Someday I'm going to fix those 2 bugs, so in the common case where you add the crystal and battery and just try the examples, the clock will automatically to your correct local time.
Paul,
I don't consider #1 a bug.
Time should always be kept and tracked in UTC.
Using anything else breaks time keeping particularly when using
the time or comparing the time to an external device or to a time in some other locality.
(Think alarms sync'd to google calendar, or events synchronized to a cell phone)
The unix guys figured this out 40+ years ago. Always track time in a common epoch, then convert
it to the users local time zone when necessary as the human wants to see it.
i.e. timezones are a human creation and are only for the convenience of the human viewer.
The CPM/DOS/Windows guys never understood this and only tracked a local date/time
in human readable form.
Tracking date/time as a broken down local time is a bad idea, not only because it makes tracking and comparing
times much more difficult but because it makes an assumption of locality. If you are not in
the assumed locality the time is wrong. Or if you are trying to compare times from two
different localities, things don't work. This does not happen when using a single epoch.
Using a epoch timer tick to track time, solves the complexity in tracking time
and comparing times, but once you start attempting to offset that epoch by some sort of local time offset,
all kinds of bad things will start to creep into the code and things become a mess.
The problem is if the epoch is shifted, then you have no idea what time it really is from looking at the epoch tick counter,
since the counter is no longer an epoch and there is nothing in the epoch counter value to indicate that it is offset
from the real epoch.
If you were going to do anything, then my preference would be keep the time tracking in UTC using
a single common epoch as it should be,
and then set the users timezone offset automatically for them.
That way you don't break the true timekeeping and all the existing time functions like:
mktime() localtime() asctime(), gmtime(), etc.. will still continue to work properly.
I've been through many date/time tracking issues in quite some detail, as I was involved
with some Scuba Diving s/w that logged dive information in a database.
Tracking the date/times of dives sounds so simple at first but
it can actually get quite messy because of the way different dive computers track time
and the way most people tend to think of "time".
Typically when diving, you are traveling to some other location which is a different timezone from you own.
Having to deal with epoch times vs local time tracking is a real mess for s/w trying to figure
when the dive was actually done.
Also, when storing the logging information in a data base you want it to be consistent no matter where
you are physically standing or where the dive was done, when you later review the log.
Then you have the issue of trying to figure out the amount of time between dives.
If all you have is a local time, you can't figure this out with 100% reliability because the local time
does not have any locality information to indicate the timezone offset and the two dives
might not have been done in the same timezone.
I know that Michaels Time library only used GMT and didn't deal with timezones.
But consider where he lives:
We had conversation about it one time, and joked and laughed about how timezone was not an issue that
he had to worry about.
In the end, the only thing that really works for all situations,
is using a single epoch and then converting to timezone offsets
as needed. The unix guys really did get it right way back then.
Maybe I can help you get the time stuff in Teensy working "properly"?
--- bill