Exact match. Not showing close matches.
PICList
Thread
'[PIC]: Calender to seconds routine.'
2003\04\11@061831
by
cdb
|
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, spam_OUTcdbTakeThisOuT
barnard.name on 31/03/2002
--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspam
@spam@mitvma.mit.edu
>
2003\04\11@092934
by
Jason Harper
|
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-request
KILLspammitvma.mit.edu
>
2003\04\11@190454
by
cdb
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, .....bodgy1KILLspam
.....optusnet.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
EraseMEpiclist-unsubscribe-requestspam_OUT
TakeThisOuTmitvma.mit.edu
>
More... (looser matching)
- Last day of these posts
- In 2003
, 2004 only
- Today
- New search...