Searching \ for '[PIC]: Calender to seconds routine.' in subject line. ()
Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Calender to seconds routine.'.

Exact match. Not showing close matches.
'[PIC]: Calender to seconds routine.'
2003\04\11@061831 by

I'm playing about with a Dallas  RTC iButton DS1994.

I have a query about the Maxim suggested algorithm for converting
time to seconds. I'm obviously missing a subtlety, I just can't see
what it is.

My Algorithm to convert datetime to seconds. Using year 2000 as year
zero.

elapsed_days =365 * (year-2000) + LeapDay(1) + no_of_whole_month_days
+ number_of_current_month_days + LeapFlag - 1

elapsed_seconds= 86400 * elapsed_days + secs +  (60 * minutes) +
(3600 * hours)

Maxim/Dallas have the following method

Sv = td->year + 32 - 2000;    I don't understand the reason for
the 32.

Xv = 365 * (Sv-2) + (Sv-1)/4 + dm[td->month] + td->day + Bv - 1;

Xv = 86400 * Xv + (ulong)(td->second) + 60*((ulong)(td->minute) +
60*(ulong)(td->hour));

I can't see why they have the Sv-2 and Sv-1/4 correction. There is an
error in there program I noticed the hours should be multiplied by
3600 and not as they have 60. They use 1970 as year zero.

At this moment I can only assume the 32 is a type of error correction
mechanism in case of transmission failure. The Leap year flag is
calculated earlier on in the program.

After this I just hope everything will fit into my 873.

any thoughts much appreciated.

Colin
--
cdb, cdbbarnard.name on 31/03/2002

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu>
Colin wrote:
> Maxim/Dallas have the following method
>
>       Sv = td->year + 32 - 2000;    I don't understand the reason for
> the 32.
>
> Xv = 365 * (Sv-2) + (Sv-1)/4 + dm[td->month] + td->day + Bv - 1;
>
> Xv = 86400 * Xv + (ulong)(td->second) + 60*((ulong)(td->minute) +
> 60*(ulong)(td->hour));
>
> I can't see why they have the Sv-2 and Sv-1/4 correction. There is an
> error in there program I noticed the hours should be multiplied by
> 3600 and not as they have 60. They use 1970 as year zero.

1970 is not a convenient base year to use for date calculations, since it's
not a leap year.  The code instead uses 1968 (2000-32) as its base; the
(Sv-2) adjusts the results to be relative to 1970.

The (Sv-1)/4 is the leap year adjustment.  Note that this division must
round down for the result to be correct.

I have no idea what the Bv variable is supposed to be - it's not set
anywhere in the code you posted.

The hours ARE multiplied by 3600; there's no error.  Take a closer look at
what the parentheses on the right of the first '60*' actually enclose.

The code will break in the year 2100, unless Bv turns out to be a
correction for that.
Jason Harper

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu>
On Fri, 11 Apr 2003 09:27:13 -0400, Jason Harper wrote:
I have no idea what the Bv variable is supposed to be - it's not set
anywhere in the code you posted.

Ah thanks for that Jason.

The Bv is the leap year indicator, that is takes the value 1 or 0 .

I must have missed out one set of parentheses when I rewrote it for
my code testing, as the seconds to time conversion failed at the
hours conversion, returning zero all the time, until I altered it to
the algorithm I used.

As I'm using 2000 as the base year, I should be OK .

Thanks

Colin
--
cdb, bodgy1optusnet.com.au on 12.04.2003

I have always been a few Dendrites short of an Axon and believe me it
shows.

Light travels faster than sound. That's why some people appear bright
until they speak!

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu>

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...