How to Convert Date And Time To System Elapse Tick

kongfu1 · Joined: 26 Apr 2010 Posts: 56

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

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

http://www.ccsinfo.com/forum/viewtopic.php?t=36475
http://www.ccsinfo.com/forum/viewtopic.php?t=37354

ezflyr · Joined: 25 Oct 2010 Posts: 1019 Location: Tewksbury, MA

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

barryg · Joined: 04 Dec 2006 Posts: 41

Cool. When I think GPS, Nixie tubes are the first thing I think of Smile

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.