Go Down

Topic: Time Library added to Playground (Read 77643 times) previous topic - next topic


Mar 27, 2010, 05:07 am Last Edit: Mar 27, 2010, 05:08 am by newhobby Reason: 1
Hi mem,

I downloaded the new library, but I'm still having the same issue.
Here is my code running on 0018.
Code: [Select]
#include <Time.h>
void setup()
 setTime(8,29,40,1,1,0); // set time to 8:29:40am Jan 1 2000


void loop()

And here is what I get:


Hi mem,

Never mind...
I had some old library that got moved when I upgraded to 0018.
Everything is fine.


I have some problems with the Time Library. I described my problem in this thread:
And since this is the "official" thread for the Time Library it probably won't hurt if I post it here too.


Hi, I'm having trouble syncing the time with processing. I have the arduino powered with a power supply. I would sync it by attaching the usb/serial. Syncing works fine but when I go to detach the usb, the arduino resets, therefore wiping out the time sent in.

Is there a solution for this?



Mar 30, 2010, 05:44 am Last Edit: Mar 30, 2010, 05:44 am by mem Reason: 1
My Duemilanove does not reset when the USB cable is disconnected (although it does reset when the cable is plugged in)
What board and operating system are you using?


Mar 30, 2010, 06:14 am Last Edit: Mar 30, 2010, 06:31 am by mistergreen Reason: 1
I just did more testing.. The board resets when I close the processing sketch before I pull out the USB.

I pulled out the usb first this time. thanks.

I'm on the duemilanove as well and on osX.


Sounds like you are good to go, but if you do want to disable auto-reset, there are some tips in the playground article: http://www.arduino.cc/playground/Main/DisablingAutoResetOnSerialConnection

have fun!


cool, thanks. the 120 ohm resistor is a quick solution. I don't have to worry about the board resetting anymore.


I'm curious as to how the the library deals with the overflow? Does anyone know if it handles the overflow cause it uses the arduino's offset from start up to calculate?  Any insight would be helpful.


Apr 02, 2010, 12:14 am Last Edit: Apr 02, 2010, 12:17 am by mem Reason: 1
it is not affected by the Arduino millis overflow.

overflow in the Time library happens a thousand times less frequently than the millis overflow (because the Time library works in seconds, millis in  milliseconds).  Because a time of zero is 1970, the first overflow will not happen until 2038.


Thanks alot mem that really helps! One more question with the time library when you sync does that reset the overflow for the seconds?


The overflow for seconds in 2038  results from the maximum value of a 32 bit signed number. This is how  traditional timekeeping programs written in C store time and if one of these is used to sync the clock then it will overflow in 2038.  However,  most modern Operating systems and time sources now use 64 bit numbers to hold time and this extends the overflow to almost 300 billion years in the future.

The Arduino Time library actually uses 32 bit unsigned numbers, so it won't overflow internally until the 22 century. If your sync source itself won't overflow before then, the arduino time will actually be ok for another 100 years.


Apr 08, 2010, 05:29 pm Last Edit: Apr 08, 2010, 06:17 pm by nilspe_80 Reason: 1
I'm fairly new to the whole Arduino scene but i have done progamming before.

I seem to be having an issue with the DS1307RTC library.

I always like to check for things to make sure they worked so i started everything up without attaching the RTC and i noticed this fault where the time library thinks that it is synced ok even though there is no RTC connected.

If i'm understanding everything correctly the following occur.

in DS1307RTC.cpp
  • RTC.get is called from time.
    It declares tm as a tmElements_t
    read(tm) is called
    a transmission is started to the wire for the RTC chip
    the RTC pointer is set at 0x00
    the transmission ends
    a request is made for 7 bytes of data (i haven't fount where the 7 comes from yet :)
    then the data is recived and put into the supplied tm
    read(tm) ends and we return to get()
    get sends tm trough makeTime() and the result is returned.

The issue is that DC1307RTC.read expects the data to be returned without actually checking if any data has been returned.
tm is returned full with zeroes and since makeTime() makes the unixtime based on jan 1st 1970 ? witch is more than 0 the function to check if time has been set fails in the below bold code.

Code: [Select]
 if(nextSyncTime <= sysTime){
     if(getTimePtr != 0){
       time_t t = getTimePtr();
     if( t != 0) // <== Fail here :)
       Status = (Status == timeNotSet) ?  timeNotSet : timeNeedsSync;        

I haven't gotten around to fully understand everything of the coding so i apologize if i have this all wrong.

The two solutions i can think of is either
1. make sure the RTC.read notices that the rtc is not connected and make RTC.get return 0
2. only accept time set bigger than makeTime() return from a call with tm full of only zeros
2. see no 1 ? :-[ ( I noticed y2kYearToTm() is used in RTC.read, this adds 30 to the year, so it is not all 0's being passed to makeTime() )


The code does assume that the RTC is working and permanently connected. I will add the capability to detect presence of the hardware to the feature requests for this library.

BTW, tmNbrFields comes from the enum named tmByteFields defined in time.h.
You may want to read about enumerated fields (enum) in a C language reference to see how this works, but the basic idea is for an enum starting from 0, the last enum value is the number of preceeding elements. In this case, that is 7


weekday() is wrongly documented.  The document says Sunday is day 0, actually Sunday is day 1, and it runs from 1 to 7, not 0 to 6.  Here is the proof of the pudding from the library code:

tm.Wday = ((time + 4) % 7) + 1;  // Sunday is day 1

well that was a couple of hours of frustration, and I DID unfortunately RTFM

Go Up