Last modified: 2010-05-15 15:38:28 UTC
In Preferences -> Time zone -> Local time display is one hour behind for me. I'm using Firefox 1.0.3, and this was observed in the commons wiki.
I'm not sure what the bug is here - that field displays the time *as currently set* by the box below it. The reason it is an hour off is presumably because you set it in the winter and it's now "summer time"/"daylight savings time". To correct it, adjust the offset appropriately. Now, there are two things I can think caused you to consider this a bug: 1) you expected summer time to be taken into account automagically (in which case see bug 505) 2) you misunderstood the phrase "local time display" to mean that this was a clue to how you *should* set the offset, not an indication of how you have *currently* set the offset (in which case can you think of a better label?) If I have misunderstood the situtation, I apologise, and please clarify.
Ah ok, then the problem is with the "Fill in from browser" function. The Offset is not getting calculated right then. Clicking Fill in from browser leaves it as "-00:00". Here's a sample from current time: Server time 18:27 Local time 12:27 Offset¹ -00:00 My actual time 13:27
(In reply to comment #2) > Ah ok, then the problem is with the "Fill in from browser" function. The Offset > is not getting calculated right then. Clicking Fill in from browser leaves it as > "-00:00". Here's a sample from current time: Hm. Works for me (Firefox 1.0.4 under Debian Sarge). * Can you confirm that the JavaScript is in fact being called correctly (if you empty the box, does it fill itself when you press the button)? * What does Firefox think is the current time - try putting the following URIs in your address bar: data:text/html,Offset is <script>document.write((new Date()).getTimezoneOffset());</script> data:text/html,<script>document.write((new Date()));</script> * What does Linux think is the current time? (Run "date" in a terminal window). If you have a dual-boot system, there may be some confusion caused by the different ways Windows and Linux deal with DST - Windows changes the hardware clock, Linux normally applies an offset on top of the hardware clock. Or maybe it's not set right at all...
(In reply to comment #3) > * Can you confirm that the JavaScript is in fact being called correctly (if you > empty the box, does it fill itself when you press the button)? Yes, it fills -00:00 every time. > * What does Firefox think is the current time - try putting the following URIs > in your address bar: > data:text/html,Offset is <script>document.write((new > Date()).getTimezoneOffset());</script> > data:text/html,<script>document.write((new Date()));</script> I got: Offset is > data:text/html,Tue Jul 05 2005 17:48:29 GMT+0000 (UTC) > * What does Linux think is the current time? (Run "date" in a terminal window). I got: Tue Jul 5 17:49:14 UTC 2005 > If you have a dual-boot system, there may be some confusion caused by the Nope, just Slackware
I just realised that it should probably say CDT instead of UTC, I've even set the timezone correctly. KDE must be messed up somehow.
(In reply to comment #4) > I got: > Offset is > data:text/html,Tue Jul 05 2005 17:48:29 GMT+0000 (UTC) Arg, I hate form submissions with no preview and no edit - there should have been exactly two lines there, each being a different URI. Anyway, it demonstrates what I hope it would, which is that Firefox thinks you are in a timezone with no offset from UTC... > Tue Jul 5 17:49:14 UTC 2005 ...and so, it seems, does the whole of Linux. Given that 'date' in a terminal gives the wrong answer, I suspect it goes deeper than KDE - unless running it from a real terminal (outside X) returns something different? Try running 'tzconfig' (you may need to be root, or use 'sudo tzconfig', or whatever) and see if that has the right answer - or is that where you've already set it correctly? [Marking "invalid", as it's not a bug in MediaWiki, though I'll happily try and help you track it down]
Got it working, thanks! The function works as expected now.
