> > Use 24 hour time internally. =A0Whether you then display 24 hour or
> > 12 hour time with AM/PM is only a matter of the display logic

> That's what I do with my clocks. Even using minutes for long-range
> (years) calendar functions such as alarms and intervals. Internally only
> seconds and minutes, and the display is updated after division by 1440
> for days and a look-up table for day name/date/month. The maths and
> manipulations are so much easier using just one basic unit

> The complications of hours, 12/24, days, weeks, and years need only
> be attended to for display and are a handicap for working out how
> many minutes are between 10:31am 15th April and 11:07pm February
> 4th and when to set off regular alarms in that interval

For completeness - leap years will require you to add a little extra
logic to that, both in the actual counting and in the display
conversion. (Leap year adjustment simply counts 2,102,400 minutes and
then adds an extra whole day and then resets OR (easier) resets at
START of the added day and count to 2,103,840 before retriggering.)
Display needs to know it's Feb 29th. eg if leap_year_minutes counter <
1440 then day =3D Feb 29th ;-).

But the principle sounds sound.
Must be the alarm ... :-)


 R

(That could be reduced to display only changes by working in fixed
length years from a certain date and then leap-year adjusting at
display time - but that leads to artificial stored time.)

-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist