Version: (using KDE 4.3.3) OS: Linux Installed from: openSUSE RPMs I work with developers around the world (nothing new to many of you, I know). I would be nice to be able to set the konversation time stamp display to use UTC so that I could do +/- in my head (or as a set topic header) and not have to remember all the offsets from my local time zone. I see settings for time format, but I do not see UTC as an option. This is a low-priority request, but it would be nice to have. Thanks to all the KDE community for a wonderful experience.
Hm, but setting KDE's clock in general to UTC isn't enough, it needs to be per-app?
Why the dudgeon? Please note that it *was* entered as a "wis" not a "bug". I would even have set the priority to "Rawther low, old chum" had I seen a way to do so. My rationale is that IRC is a much more "real-time" app' than most others in a "stock" KDE install and a prime candidate for a multi-time zone environment, thus it might benefit from this ability. Local time seems quite appropriate for all the other things common to the KDE desktop. I'm far from suggesting that *all* app's might need this feature, only commenting that it would be a nice grace-note to this one.
There was no dudgeon intended; sorry if it read like that. I'm not a native speaker (nor are most KDE developers). I was merely interested in a clarification of your use case. For an application developer, adding another option is relatively easy. In fact, it's often the easy way out: Rather than making an effort to identify an underlying need that might be served better by a design change, an option gets added. Or it gets added to avoid making a hard decision, or to realize a more sophisticated implementation that obviates the need for the option. Over time that translates to a huge burden on both the user (way too many options instead of inherent well-designed behavior) and the developer (maintenance), so a decent developer will approach any suggestion of a new option with "Is it _really_ needed, or is there a simpler/better way?" Don't mistake that for dudgeon, rather it's collaborative brainstorming. Open source is participatory; when you file a request here, you basically agree to be drafted to involve yourself in the design process :).
"or to avoid having to realize a more sophisticated implementation", rather.
On Tuesday, 02 February 2010 1233:59 Eike Hein wrote: > https://bugs.kde.org/show_bug.cgi?id=225189 > --- Comment #3 from Eike Hein <hein kde org> 2010-02-02 19:33:47 --- > There was no dudgeon intended; sorry if it read like that. I'm not a native > speaker (nor are most KDE developers). And I have forgotten most of the German, Russian, and Viet I used to have, too. No offense taken, I was caught off guard by the form. > > I was merely interested in a clarification of your use case. Thank you. I tried to include that with my reply. > For an > application developer, adding another option is relatively easy. In fact, > it's often the easy way out: Rather than making an effort to identify an > underlying need that might be served better by a design change, an option > gets added. LOL! Yes, I quite understand that concern. I have received steam from more than one user when I suggested a more global approach to a request. Bells & Whistles are not my intent; I love a "clean" app'. > ... so a decent developer will approach any > suggestion of a new option with "Is it _really_ needed, or is there a > simpler/better way?" Agreed. Did I succeed in making clear that I think the request applies fairly narrowly to IRC, rather than making a single choice of time display for the whole desktop? > > Don't mistake that for dudgeon, rather it's collaborative brainstorming. Point taken, and my apologies for a somewhat acerbic reply to your first. > Open source is participatory; when you file a request here, you basically > agree to be drafted to involve yourself in the design process :). Understood and I am quite willing to do whatever I can. My programming languages are a bit archaic, but I can document and analyze, even with 7 decades of wear & tear on the brain. Best regards,
Yup, I do see your point as to why there's value to having the universal time in the IRC client as opposed to the rest of the system due to both serving different contexts, one being communication with folks in other time zones and the other being activities in your local time zone. As such I'm OK with keeping the ticket open and not opposed to adding the option. That said, I do want to point out that the KDE Plasma Desktop's clock allows one to select multiple time zones in its configuration, and to subsequently switch between them by rolling the mouse wheel above the clock. Hovering the clock also brings up a tooltip showing the times in all selected timezones. I realize your point is that you want to have the info close to where you need it, that is in conversation, but at the bottom line it might still be more convenient to hover the clock and read the right time directly than do the calculation from an UTC timestamp. Another thought I have is this: KDE ships an address book application. Konversation integrates with KDE's address book: It's possible to associate nicknames encountered on IRC with address book contacts. When hovering a nickname in the nickname list that has an associated address book contact, we show information pulled from the address book there, such as the real name. Address book contacts also have a data field for geographical location. Assuming we have a lib somewhere in KDE that can hand back the time for a given pair of geographical coordinates, we could display the local time at someone's location in the tooltip as well, saving you any manual calculation as long as you maintain address book associations and geographical location data for your address book contacts.
Thanks - Yes, I understand Plasma clock - I was thinking of the time stamps in the log of the chat window more than moment-by-moment knowledge during use. I parse the log programmatically for planning/design/commitment data and it would be easier to work from UTC than to have to place everyone based on offset from my own zone. The Address Book connection is a new thought - that might be a good thing to experiment with - (In fact, I just noticed some of that option today while entering a UK address :: I saw the Lat/Lon map - :: This bears further investigation.) This could solve both issues, on-line and log calculations.
err, well, not log stamps... sorry