I think for the folks who may not necessarily be in California, all of the webtools, including Tinderbox, Bonsai, and Bugzilla, should show the times they give in the form of either "xx:xx PST," or show them in Greenwich Mean time (now known as Universal Time Coordinated, or UTC), in the form of "xx:xx UTC."

All times are PST unless otherwise stated. When these tools were first developed, there were only used by developers in Mountain View. That is why there is a lack of timezone labeling. I will add the timezone to the time at the top of tinderbox. I would rather not add it to everytime in the left hand column. That would be overkill. If you have ideas or patches for how to fix other pages. Let me know.

I made the change to tinderbox. You might try posting to the webtools newsgroup, news://news.mozilla.org/netscape.public.mozilla.webtools/ to see if anyone is interested in making the changes to bonsai. I have not done any work on bonsai. You are right that everything should probably be in UTC, but since everyone is used to seeing PST times I am not sure if switching would be a good idea. If you wanted to make that change, it would be important to get people involved on the newsgroups.

I agree it would probably be overkill (as well as redundant) to put the timezone info in the columns as well. And if it were ultimately to be done The Right Way(tm), with it being specified from the start that 'all times are in UTC unless otherwise noted' (or something to this effect), then ideally one wouldn't even have to worry about the complication of putting timezone info in the columns. I do understand why the times ended up this way--I am used to PST myself, living here in Newark, California. In fact, I only just suddenly started thinking about this when I just suddenly realized that through mozilla.org, people from all over the world are already looking at this, so between this and the strong internationalization effort going into Mozilla now, I think it would make sense to cater for this expanded audience by internationalizing these webtools a little. Actually, IMHO, though it might take some getting used to if you were to switch to UTC, I still think this ultimately might be the right way to go... Perhaps it would ease the transition if you were to put the times in the columns in UTC, but for the "master clock" at the top (for lack of a better term), change it to say someting like "It is now xx:xx PST (-0800 UTC) in Tinderbox Land", just to remind people that our time is 8 hours behind UTC? (Correct me if I'm wrong here on the 8 hours part.) My reasoning behind this is that this way, UTC can be used for all the critical fields (like the checkin times in the columns), and for those of us used to PST, we have the conversion formula stated right there at the top, to help ease the transition. Just a thought. I agree, it would probably help to get more input on this. So I will post to the webtools newsgroup on this as well... See what people say about this. Also, would it help if this bug got assigned to the Bonsai and Bugzilla folks? There is one last issue here which might complicate a transition of course... That is, how to convert--in particular, I am imagining it might be tricky to convert all of those bugs from the past in Bugzilla's database over to UTC or give them timezone info...

I think UTC is there to _store_ times in it, but not for human reading. If the times was shown in UTC that mean almost everyone had to convert the times to their own to understand it. (Unless you live in the England's timezone _and_ it is winter.) It would however be nice, if the times were showed in LOCAL time of the web user. It is possible to do this? Is the web browser sends this information? If it isn't, that would require the user to set some preferences (stored in cookies), so it might not worth the trouble anymore. Actually it doesn't matter what a program stores the times in as long it is consistent, and a program can convert accordingly. Problem is that no timezone is consistent that uses DST.

I wonder... Problem is, I am guessing that any mechanism that would allow the times to be displayed in the viewer's local timezone would require JavaScript or Java... Is this correct? I know Terry doesn't like the idea of using JavaScript and/or Java in Bugzilla, so if the usage of DOM features in Tinderbox/Bonsai is also a no-no, then I guess there is nothing else one can do. Still, I think since UTC is the standard way of designating time in international settings, this still might be the way to go. I do think a DOM-type feature that would enable display of the times in the viewer's local time zone would be the logical next enhancement to this, however.

It amazes me there isn't a solution to time zones in HTML/CSS, ie a <TIME> or <DATE> tag that can be automatically converted to the local time.

There is one major problem with something like this: the W3C has clearly stated over and over that HTML is designed to be a **STRUCTURAL MARKUP LANGUAGE**, NOT a programming language, a layout language, or a scripting language. Therefore, I think the idea of adding sucha a tag to HTML/CSS would be a TERRIBLE idea. However, not all hope is lost; this idea has set me thinking--I wonder now if there isn't some way one could use JavaScript or Java to do something like this. This could potentially make everyone from every local time zone happy. And after all, JavaScript/Java would be much better suited to this purpose than HTML/CSS. Of course, it would undoubtedly be much simpler (and more internationally-correct) simply to show the time in UTC, but the JavaScript/Java idea is probably more likely to win the support of folks who are used to working in their local time zone (e.g. Netscape).

Oops--I just thought of one other potential problem to consider: the JavaScript/Java idea would make the webtools less Lynx-friendly. :-( Darnit--this is not as easy a problem as I first would have thought. I guess showing UTC times is the only REAL solution in this case.

On the other hand, since Lynx would not be good at showing tables anyway (like the ones Tinderbox depend heavily on), perhaps it wouldn't matter... Anyone else have any thoughts about this?

Huh? What I was describing was exactly the spirit of HTML! A time/date is content, and the time zone and way to display format is style - the style sheet saying to convert to the local time zine. Dates are content in as much as normal text or images are.

Agreed--time and date are content. However, HTML is also not a content language. It is a *structural markup* language. In other words, it is a set of generic tags designed to tell the browser something about the *form* of a document. It is not designed to convey specific content at all. That's why I say Java/JavaScript would be the right thing for this--something to do *dynamic content*--that is, content that is generated at the time of viewing, and that will differ everytime the document is viewed.

I have had to be careful to make tinderbox work even when javascript is turned off. In the past, if I made a link only work with javascript, people complained. We should either use PST or UTC (and be consistent everywhere).

If the cookie timezone isn't set, add a javascript function to the page. When the javascript is inserted in the page it contains the server time when the page was generated. The javascript code then calculates the difference between the server time and client time (and perhaps does some quantization) and sets the timezone cookie accordingly.

M18.

Why not set UTC as the default time, and add time zone selections to prefs? Check out Slashdot's "Customize Homepage" menu, where you can not only set the the time zone, but also select a date/time format.

marking this bug fixed. tinderbox now shows local time and time zone at the top of the page. This satisfies the reporter's original request. Making the time zone user configurable as suggested in later comments would only make things more confusing since every tinderbox viewer would see something different and statements like "your 10:00 checkin" would no longer mean anything. Let's keep it simple

Unsetting target milestone so we can delete the old (inappropriate) Mozilla target milestones from Webtools.