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. -- [tim@localhost ~]$ uname -r 2.6.27.25-78.2.56.fc9.i686 Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
