synchronize time

[jdow]

Sigh - twit filter.

I keep at least some timekeeping around here in UTC specifically for the
unambiguous logging it provides. In the past I have maintained clock to
UTC when I kept manual logs. I can see perfectly valid reasons to have
a computer timezone set to UTC. But, I guess you're not only irritating
and irritable but also unimaginative.

Have a nice day.

{+_+}

On 2012/03/07 23:50, Tim wrote:
> Tim:
>>> You are misdiagnosing cause and effect.
>
> jdow:
>> Now you are being imprecise.
>
> Cause and effect:  Has CUPS stopped working because UTC is set?  Is the
> time set wrong, and has CUPS stopped working because the time is set
> wrong?  Is CUPS faulty?  Has CUPS merely indicated that something else
> is wrong?
>
> Misdiagnosis:  CUPS browsing has stopped working.  Hmm, I'll blame CUPS,
> and the UTC flag.
>
> Correct diagnosis:  CUPS browsing has stopped working.  Changing UTC
> flag changes behaviour.  Investigate whether I've got the clock set
> right.  Does setting the time configuration cause CUPS to start working
> properly again?  Yes, there's nothing wrong with CUPS, the fault was
> external.
>
> Of course, if you don't understand how to properly set the clocks,
> you're going to paint yourself into a corner with the wrong diagnosis.
>
> I've brought up CUPS again, as the original posting used it as the thing
> that noticed a problem, the original poster continually insisted CUPS
> had a problem (when it didn't), right up to the last post they responded
> to me on the list with.
>
> Now onto discussing time, as time setting is the problem, CUPS was just
> the thing that brought the error to people's attention.
>
>>   Do you mean UTC time zone setting
>
> I'd never seen a UTC "timezone" setting, nor even heard of anyone
> referring to one.  Likewise with Greenwich Mean Time.  It's not a zone
> (GMT or UTC), as such, but a reference point.  Only KDE seems to offer
> it as a choice, and it's a highly illogical choice.  And I'd not
> mentioned, in any way, UTC as a timezone setting in prior messages.
>
> If you live in Greenwich, do you run your clocks on GMT?  No.
>
> Can you live in UTC?  No.
>
> Does any country have a timezone which is exactly the same as UTC?
> (Same hours, no daylight savings / summertime.)  I don't know.  But,
> logically, and to prevent people doing silly things, you'd really want
> to call such a timezone by the name of the timezone (country/local).
>
> Is there a practical point in having a computer show UTC as its
> displayed time.  Yes, perhaps...  Such as a server that people will
> manage from different international locations, and you want to try to
> force them to think about the time, and only have to do one calculation
> (there time against UTC, rather than figuring out the difference between
> two different timezones).  But it's still a rather foolish and illogical
> thing to do.  It's more pragmatic to set the timezone to where the
> server really is, and let the software manage that for you.  I'd say
> that the only computer where it makes complete sense to have it say it
> lives in UTC, is *a* timeserver machine.
>
>> UTC hardware clock setting
>
> The only option I have ever seen, on any release, other than checking
> out KDE recently, refers to a flag that say the hardware clock has been
> set to UTC, or not.  And I've specifically been saying that the UTC flag
> refers to the hardware clock, and that it must reflect what the clock is
> set to, in my prior messages.
>
> KDE's configurator seems rather poor in that it will let you set a real
> timezone, or a pseudo-UTC one, but has no additional flag to say how you
> want the hardware clock to be run.  One has to presume that it
> automatically does something to make it correct when you set the clock
> (set the UTC flag, or set the hardware clock to match the time according
> to how the UTC flag was already set).  If this doesn't actually work,
> though it appears to here, then that's a fault that can be raised (but
> with the KDE date and time tool, not a CUPS issue).
>
> The Gnome tool, at least, lets you separately set whether the
> "system" (hardware) clock is set to local or UTC, set the date and clock
> to a specific date and time (or let a NTP server do so, for you), and
> set the timezone (with no obvious listing for an illogical UTC timezone
> that doesn't exist - there may be some timezones that are the same as
> UTC, but UTC isn't a timezone).
>
>> the UTC/LOCAL indication in /etc/adjtime (the check box on the time
>> zone setting tool)?
>
> I haven't mentioned the configuration file that it's set in.  And if one
> is using one of the configuration GUIs to set the time, it hasn't really
> been important to the user how and where the setting is set.  But
> anyway, set it by hand, or let the configurator set it for you, and the
> result's the same.  *It* is the UTC flag.
>
>> This is known working:
>>       HARDWARE    CHECKBOX    TIMEZONE
>>          UTC         UTC         ANY
>>          LOCAL       LOCAL       ANY
>
> The above two are the only way to correctly set the time.
>
>> These are known to break at least NTP:
>>       HARDWARE    CHECKBOX    TIMEZONE
>>          UTC         LOCAL       ANY
>>          LOCAL       UTC         ANY
>
> The above two would always be incorrect, and I wouldn't expect anything
> to work reliably on such a system.  I wouldn't really care if they
> didn't, because you shouldn't expect things to run properly under faulty
> conditions.  I certainly expect anything that does date comparisons to
> mess up when the time is set wrong (all aspects of clock setting, not
> just that you might put in 4pm instead of 5pm).
>
> Furthermore, I wouldn't be at all surprised that some services may well
> need restarting after changing the time.  More so if you've happened to
> set the clock backwards.
>
>
>> You still ignore the correct two places that must agree for "everything"
>> to work, the setting for the motherboard clock must be either UTC or local
>> time and that information must be telegraphed to the OS with the value in
>> the third line of "/etc/adjtime" which is apparently set by the appropriate
>> checkbox on the time zone setting panel.
>
> No, I haven't ignored that, at all.  Haven't you read my messages?  I've
> said, numerous times, that the UTC flag must reflect what the hardware
> clock is set to.  I've explained it briefly, I've explained it in
> detail.
>
> How and where that flag is being set isn't the issue.  And unless
> someone mis-setting this specifically says whether they were using a GUI
> or hand-diddling configuration files, that's not a route I was going to
> go down.
>
> My approach has always been to say *what* needs to be done, not *how* it
> should be done.  e.g. If I were to tell someone to rename a file in
> their homespace, the last way I'd tell them to do that would be with a
> list of instructions for what commands to issue, or what steps to take
> with a certain file browser.  I'd say, delete *this* file.
>
> More so, for this reason, too.  From my memory, it was /etc/localtime
> (linked to a timezone file, or not), and /etc/sysconfig/clock, but
> not /etc/adjtime, that were the configuration files for the hardware
> clock being set to localtime or GMT.  And that /etc/adjtime was a file
> that NTP used for itself (and possibly a NTP equivalent replacement
> program).
>
> If one's using a configuration tool to set these things, then it should
> handle all aspects, correctly, for you (set the clock to the right time,
> set the timezone you've picked, set the UTC flag if appropriate).  The
> Gnome and KDE tools appear to be doing their jobs, here.  No amount of
> fiddling with them has managed to break CUPS browsing, for me.
>
> And that's why, all the way along, I've talked about setting the
> UTC/not-UTC flag for the hardware clock to match the hardware clock,
> *and* set the timezone correctly (two different things, mentioned
> separately).
>
> The person with the problem should really state what they're using to
> set things.  Then we can guide them through using that thing, rather
> than start them off using unfamiliar tools.  Sure, get them to switch
> tools if you have to, as a second approach.
>
> NB:  I am also looking at Fedora 16, not just Fedora 9, I happen to be
> typing this email on a different computer (before someone jumps to the
> obvious wrong conclusion when they look at my email signature).
>
>>> The simple proof is, if you have set the clock configuration correct,
>>> CUPS browsing will work.
>
>> He has said he made it correct. Apparently he meant making the motherboard
>> clock and the checkbox agree. He was NOT talking about timezone setting.
>
> I've barely mentioned timezone settings, in as much as setting it
> correctly, and certainly never mentioned attempting to set UTC as a
> timezone (it's not really what you'd call a timezone, anyway).  I've
> been been discussing, over and over, UTC/not-UTC flag for the hardware
> clock.
>
> Just where do you see an option that lets you set UTC as a "timezone"?
> KDE is the only place I've seen that.  And I don't recall Aaron saying
> what he's using.  And one really should (say what they're using) if one
> is using something other than the default GUI Fedora uses (Gnome), even
> if it is damn annoying (Gnome3, at least, in the latest incarnation).
>
>
>> At worst Aaron is guilty ONLY of imprecision in telling us what he had
>> to do.
>
> That's been obvious, for some time.  It seems he doesn't understand the
> aspects that are involved in setting clocks, particularly in a something
> designed for an international environment.
>
>>   We cleared this up in private emails.
>
> Well, there's certainly been no indication that things have been cleared
> up in public emails.  Quite the contrary.  All the public emails have
> indicated that things are not right (i.e. insisting, right up to the
> last email, that setting UTC stops CUPS from functioning correctly).
>
> If Aaron and you have been guilty of one thing, it's of *interpreting*
> my mails, instead of reading what they actually say.  Do not take what I
> say to actually mean something else, nor to allude to something, take it
> as what it actually says.
>
> I've explained the settings involved in the clocks, in depth.  I've set
> them out in one-line descriptions.  I've described and explained the
> different clocks.  I've explained the pluses and minuses of setting your
> hardware clock on UTC or localtime.  The information has been there in
> several different ways for someone to be able to grasp at least one of
> the explanations, or to ask for clarification.
>
> If Aaron wants to persist in saying that CUPS browsing doesn't work when
> the clock is on UTC, then let him submit a bugzilla report.  I think we
> know what the answer will be:  No, CUPS works either way.  You've got
> your clock configurations set wrong.  Read the docs and set them right,
> or report a bug in the tool you used to set the time.
>
> And no, I'm not setting out on a personal attack on Aaron.  It's always
> been about fixing the right fault, and how the clocks should be set.  If
> one wants to persist in arguing from the wrong end of the stick, whoever
> they are, they're going to keep getting told (by someone) that they're
> doing it wrong.  This isn't Windows, you can't just keep rebooting until
> something different happens.
>