next topic »

[Reply #15 on:]

thanks... works very well...

You're very welcome, thanks for the feedback.  Unfortunately, it's that time of year 

[Reply #16 on:]

Hi,

this library works only with RTC's?
Is there something like "Auto Daylight Savings Time" for ntp?

[Reply #17 on:]

Hi,
this library works only with RTC's?

Hello!  The Timezone library is unaware of RTCs; it will work with or without one.  It simply converts time values stored in time_t variables.  Include the Arduino Time library to define the time_t data type.

Is there something like "Auto Daylight Savings Time" for ntp?

NTP sends UTC only, without adjustments for daylight time or time zone.

[Reply #18 on:]

NTP sends UTC only, without adjustments for daylight time or time zone.

Thats the reason i was asking. So i can do it like my router with your library.
There i can set the Time Zone and NTP Time Server and have a Auto Daylight Savings Time checkbox.

Now i see "the Time library will function as a software RTC without additional hardware" in the readme.
So the first sentence "A primary aim of this library is to allow a Real Time Clock (RTC)" did confuse me.

[Reply #19 on:]

So the first sentence "A primary aim of this library is to allow a Real Time Clock (RTC)" did confuse me.

Hmmm, yes, thanks for pointing that out.  I'll give some thought to clarifying that.

[Reply #20 on:]

I like the library and I may use it for an upcomming project but it really makes my head hurt
because I have 30 years of using unix time functions burned into my head.
With the unix time functions you never calculate a time_t value for a local time.
There is typically a single system time_t (which is always utc) and then you convert that to a struct tm
using localtime() where you apply the timezone offsets and any potential DST offset to get
the broken down time values.

This library takes a different approach of converting from the normal/system time_t to a local time_t.

Then there is the differences that Michael did when he created the Time library
Michael deviated from the unix time functions by changing some of the paramters from being zero
based to being one based.
His tmElements_t wDay and  Month are 1 based wherease the struct tm tm_wday and tm_mon
are zero based.

While it call can be mad to work,  it always makes my head hurt when I use the Arduino Time stuff...

But nice job on the library, given the environment.

--- bill

[Reply #21 on:]

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

If I were to call localtime on a Unix machine, whose local time would I get? Whatever zone the machine was set for?

(I was reading about localtime here, looks like a nice site, don't think I'd come across it before.)

[Reply #22 on:]

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

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:

Code:

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

[Reply #23 on:]

Oh yep forgot about the user TZ variable. I was thinking that some extensions to the library along the lines you suggest wouldn't be too difficult. Actually I'm pretty used to dealing with dates and times as serial numbers, it's really the only way to go. And for the most flexibility and generality, any date/time should be stored as UTC/GMT/Zulu, this was my primary motivation with the library, to be able to set an RTC to UTC, and then also not have to worry about the daylight time changes.

Indeed the aliens will be perplexed. There have been various more or less interesting suggestions for "better" systems of keeping time but I think there is little incentive to adopting them given the investment and degree of entrenchment of the current system.

[Reply #24 on:]

I tried library with GPS time and it works well until arduino power on and it is attached to the computer, when i power it off and on arduino after some time the bare arduino library does not sync with GPS, it starts where it stopped so i got two different times. GPS time works well but library time stayed behind as long power offed?

On restart library should sync with GPS? but it is not doing?

[Reply #25 on:]

I tried library with GPS time and it works well until arduino power on and it is attached to the computer, when i power it off and on arduino after some time the bare arduino library does not sync with GPS, it starts where it stopped so i got two different times. GPS time works well but library time stayed behind as long power offed?

On restart library should sync with GPS? but it is not doing?

If you are referring to the Timezone library, it just does conversions, e.g. you give it UTC and it gives back local time. The Timezone library works in conjunction with the Arduino Time library, and the Time library has a function, setSyncProvider(), to allow it to synchronize with an external time standard like GPS, an RTC, NTP, or whatever.

[Reply #26 on:]

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

I just became aware of this post and wanted to add context to the reason for the change.
My original time library did follow Unix convention with days and months zero based (see: http://playground.arduino.cc/Code/dateTime)

Back in December 2009, There was discussion in the developers mailing list about including these time functions in the Arduino core. In that thread, David Mellis made the point that that an Arduino time API should be closer to Processing (where the days and months start from 1). His reasoning was that people moving from Processing to Arduino were less likely to understand and deal with API differences than those coming from a Unix background.  In the absence of any objections from the developer community at the time, the API was altered to be closer to Processing and the rest is history.

It is not always an  easy task to create APIs that fully satisfy beginners and boffins, and when compromises need to be made, in the Arduino world, it is right that beginners get preferential consideration.

Michael

[Reply #27 on:]

Michael,
Thank you for the bit of history.
It is always nice to see where things originated.
Sometimes I really shake my head at some of the decisions
that the processing & arduino teams have made.

--- bill