On Sun, 2012-03-04 at 14:13 -0800, jdow wrote:
On 2012/03/04 13:57, Aaron Konstam wrote:
> On Sun, 2012-03-04 at 22:39 +1030, Tim wrote:
>> On Sat, 2012-03-03 at 10:13 -0600, Aaron Konstam wrote:
>>> Whatever you theorize, here is what happened. The hardware clock was
>>> set to UTC, and the software clock was local time. However, the UTC
>>> box in system-config-date was not checked. Result was cups browsing
>>> did not work properly
>>
>> That's still not an issue of CUPS not liking the setting of UTC (how you
>> originally presented the situation). The issue of CUPS not working was
>> not one of "UTC" or "not UTC" being set.
>>
>> It's CUPS not liking you setting the clock wrongly, as may well happen
>> with other things.
>>
>> And that was the point I was making.
>>
> Well your point is incorrect. Cups browsing did not work if UTC was not
> set. TThe clocks were set correctly. The hardware clock was operating on
> UTC time and the system clock was running on local time.
There are three "clocks" you want to consider.
The battery powered HW clock is read exactly once, on boot. "hwclock" reads
/etc/adjtime. The third line in /etc/adjtime declares either UTC or LOCAL
for what time the hardware clock keeps
The system clock internally is always kept in UTC.
The clock presented to the user in the date command or ls commands, for
examples, is in adjusted automatically by the OS on queries to match the
system's time zone setting. So you have to have both time zone setting and
hardware clock setting correct or your system will get confused.
I have none of the problems you describe here with a hardware clock set to
UTC and the local time zone set to Los Angeles local time.
Can you point to CUPS documentation that requires the system timezone value
be set to UTC? (Of course, the internal clock Linux maintains is in UTC.)
{^_^}
I am tired of this argument. Everyone is saying what I said at the
beginning and then arguing with me when they say the same thing.
In the beginning you said the setting the time to UTC does not matter
and we now seem to all agree, so let us go on to something else.
--
=======================================================================
Not every question deserves an answer.
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net