![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
kongfu1
Joined: 26 Apr 2010 Posts: 56
|
How to Convert Date And Time To System Elapse Tick |
Posted: Thu Nov 18, 2010 12:15 pm |
|
|
Hi,
I am looking for a sample code to Convert Date And Time To system Elapse Tick. Memory is very limited. Please help.
Thanks.
Howard |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
![](templates/subSilver/images/spacer.gif) |
ezflyr
Joined: 25 Oct 2010 Posts: 1019 Location: Tewksbury, MA
|
|
Posted: Fri Nov 19, 2010 11:26 am |
|
|
Hi All,
This thread makes me wonder if the topic is not applicable to a project I'm currently working on?
I've designed a Nixie tube clock that currently displays only UTC time and date (derived from a GPS module). The final step of the project is to allow 'local' time and date to be displayed instead based on a programmable UTC offset. The time calculation is trivial, but manipulating the date is another matter. I've written the conditional statements for this, and they are long and cumbersome, as well as almost impossible to test in any kind of a reasonable length of time! For example the day, month, and year may all need correction depending on when the adjustment is being made!
I'm wondering if a better way would be to convert the UTC time to an Elapsed Tick and then add/subtract the appropriate number of Ticks corresponding to the desired time offset, and then convert back to time/date to get local time/date?
Has anyone faced this issue before? Any suggestions for a compact, easily-testable solution?
Thanks,
John |
|
![](templates/subSilver/images/spacer.gif) |
barryg
Joined: 04 Dec 2006 Posts: 41
|
|
Posted: Fri Nov 19, 2010 2:31 pm |
|
|
Cool. When I think GPS, Nixie tubes are the first thing I think of
I think your idea has merit. The conversions to and from ticks and dates are still messy, but at least people have been doing them for a long time, so the methods are proven, and then you can use them any way you like. I did an application that did logging and timestamping, and although I didn't have to do what you did...
Oh, wait, I did have to! Although this thing expected to be told what time it was, it was done in a way that it didn't have to know right away. The logs would store offsets from when it was turned on. Then when it got told the time, it would work back and figure out what all the other timestamps were. Subtracting the offsets from the reference time gave the true time. Then pushing it through the conversion made it look like it knew all along.
I worked out the conversions after finding this nifty little page on the Web: http://quasar.as.utexas.edu/BillInfo/JulianDatesG.html
One optimization I did was to limit the range to like 100 years...I used 16 bits and subtracted a constant. Look for "2440587" and Jan 1 1970 if you want to do this.
I don't know if this will help the original poster, but it might. Dates are messy, however you approach it. Limited memory is a bummer when math's involved. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|