Regarding the 040228 and 040229, now I see. I often use a year-month-day
format. It makes sorting by date much simpler, and, in my opinion, makes
more sense given our usual most significant digit at the left notation.
But I always use the full 4-digit year when doing this; 2004-03-01 or
20040301 for today for example. If I wrote 04-03-01, most people around
here (quite possibly including myself) would think that I meant "April
3rd, 2001", and I suppose that Europeans might think that I meant "the
4th of March, 2001". But if 040301 works for you, that's fine with me.
Regarding the 41C series accuracy factor, first off, I've never had a
41C series, so I'm just going by what's in the manual. My understanding
is that using it causes the calculator to periodically adjust the clock
by its smallest increment. And yes, I gather without using an alarm or
in any way bothering the user, save to set/adjust the accuracy factor.
The 48 and 49 series evidently weren't designed to be precision
timepieces; I have weight-driven and spring-driven mechanical clocks
that (as adjusted) are more accurate.
Using a control alarm to adjust the time on the 48 and 49 series is
certainly less than ideal, especially if a control alarm comes due while
you're trying to use the calculator. For example, if the command line
editor is active, then the control alarm will abort it. To be sure, the
command line will be saved (assuming that last command lines saves
aren't disabled), so you can use the last command lines operation to get
back to what you were trying to do, but it's still rather disruptive.
I wonder whether it's possible to periodically adjust the time without
using control alarms on the 48/49 series. Perhaps for someone skilled in
assembler language programming?
What would really be ideal would be a way to adjust the oscillator
frequency. But these calculators weren't designed to be opened, and I
don't know that the electronics design is available to the general
public.
Of course, additional niceties such as a temperature compensated
oscillator would be even better, but perhaps not appropriate for a
calculator. After all, a calculator isn't (so far, at least) intended to
be a chronometer. An oscillator is essential for the digital logic, and
a display is needed for the calculator, and having them available as the
basis of the time and date capabilities is a nice bonus.
If I recall correctly, for the HP CLK application, the user sets the
amount of the correction, and the application calculates how often to
make this fixed correction, with the option to suspend the corrections
and have any accumulated "past-due" corrections made after they're
re-enabled.
With the TIMEKEEP application, the user can easily modify the schedule
(if any) of when to make the correction, and/or tell it to make the
correction now, and the application calculates how much of a correction
is needed as part of the correction process.
It's been a while since I've used either of these, but I prefer
TIMEKEEP's method.
I suppose that CLK could be set up to make very small adjustments, but
that would increase the frequency of the control alarms, so I don't
think that I'd be happy with that.
It occurs to me that Wolfgang (see
http://page.mi.fu-berlin.de/~raut/) has some nice time and date
applications, but I don't think that any of his 48 series applications
include an automatic clock correction feature, although I know that at
least one of his 49 series applications does.
Regards,
James