I have written this script [StackExchange sites - convert dates to local timezone ][1] It applies to Stack Exchange sites, EG: stackoverflow.com, stackexchange.com, superuser.com, etc. The timezone that [the Stack Exchange sites use is UTC][2] i.e. +0000. So, this script converts the dates to your local timezone, in both: - tooltips `2015-12-14 14:11:13Z`, and in - date text like `Dec 14 '15 at 14:11` or `Dec 14 '15 at 14:11`. [superuser.com][3] It also recalculates them whenever the page changes via `MutationObserver`. ---------- Known issue: 1. While you are on the superuser.com homepage, every 1 minute the activity indicator which will show when new posts are asked or answered. Also, every relative timestamp, e.g. `answered 1 min ago` will become `answered 2 min ago`, and so on. Well, while using the script, the latter feature, i.e. "*the relative timestamps being increased every 1 min*" becomes broken, and they don't get updated anymore. ---------- The script modifies the values as follows (in my case, for timezone EEST, +0200): - tooltip: `2015-12-14 14:11:13Z` --> `2015-12-14 16:11:13` - date text `Dec 14 '15 at 14:11` --> `Dec 14 '15 at 16:11` If I try to add a `Z` to the modified tooltips, i.e. modify the line 65 to: dates[i].title = toTimeZone(temp, localTimezone) + 'Z'; therefore the text in the above case to become `2015-12-14 16:11:13Z` then the page hangs (the `MutationObserver` constantly sees mutations ). The other approach I thought, was instead of modifying all tooltips+texts on page, to attach an event listener on each, to be activated on `onmouseover` and be restored on `onmouseaway`, but I think that (apart from filling the page with event listeners is not a good idea) the issue will remain, if at the point of "every 1 min", one tooltip has modified modified value at that time. ---------- <br> *It uses the `jsTimezoneDetect` script (for getting the local timezone), and `Moment.js` and `Moment-Timezone` JavaScript libraries (for converting the dates). Also note: `jsTimezoneDetect` does not do geo-location, nor does it care very much about historical time zones, e.g. it may get "Europe/Berlin" when the user is in fact in "Europe/Stockholm" (they are both identical in modern time).* [1]: https://greasyfork.org/en/scripts/14918-stackexchange-sites-convert-dates-to-local-timezone [2]: http://meta.stackexchange.com/questions/2941/why-are-the-time-stamps-in-utc-instead-of-localized-for-the-client [3]: http://superuser.com/