Template talk:UTC time

Time zone day wrap

Currently crossing over to the next/previous day during conversion is not handled (see 00:00 or 23:59 if your current time zone is not UTC).

Would it make sense to add something like "the next/previous day" suffix to the script? E.g. 23:00 UTC (01:00 UTC+2 the next day). Another option would be introducing a [[:Template:UTC date]], but how crazy do you want to get with those edge (depending on how far off the norm you are) cases? --zeeZ (talk) 11:17, 4 September 2015 (UTC)

Is it not the same as any other clock? "00:00 UTC (01:00 UTC+1) or 23:59 UTC (00:59 UTC+1)" looks fine to me, and I don't see a problem. -Chieftain Alex 12:37, 4 September 2015 (UTC)

I just see the potential for random confusion, for example usage on Beta for example: The second public Beta Weekend Event will take place from September 4 at 19:00 UTC (05:00 UTC+10) to September 7 at 6:59 UTC (16:59 UTC+10).

Maybe even a 19:00 UTC (05:00 UTC+10⁺¹) would do. I just hate it when conversion like that wraps around but doesn't tell. --zeeZ (talk) 13:05, 4 September 2015 (UTC)

"Is it not the same as any other clock?" There's a difference between clocks and specific datetimes though. Server reset used to say "Guild missions are reset once each week on Saturday at server reset (01:00 UTC+1)" for me, which is an entire 24 hours out from when they actually reset (Sunday at 1 AM). I replaced it wa giant table that gave the day/time in different timezones, because I couldn't think of any other way to handle it, but somebody changed it back to use this template. Now, for American users, it says "Guild mission rewards: Sunday 17:00 UTC-7. (This is Saturday in the Americas.)" -- how can Sunday 17:00 UTC-7 be Saturday?? That's not how it works!

Either this template needs to accept and spit out a day, or we need a second template that does. But it relies on JS, so I can't actually edit it myself. -- Dagger (talk) 11:51, 20 September 2015 (UTC)

To quote what I see from my computer, "Guild mission rewards: Sunday 00:00 UTC (17:00 UTC-7). (This is Saturday in the Americas and Sunday in the EU, Asia, & Oceanic zones.)". This tells me that when it's 5:00 PM on Saturday where I live, in Vancouver, Canada, the servers are reset for guild missions. It tells me that my time zone is seven hours behind UTC, which is correct (I'm in PDT at the moment). Is this information wrong? G R E E N E R 12:56, 20 September 2015 (UTC)

It actually tells you that it's 5 PM on Sunday, then tells you that Sunday is Saturday. Neither of those are right. We know what it's trying to say (since we all know when missions reset, right?), I'd just prefer that the page actually said it, rather than be wrong and rely on the reader to figure it out. -- Dagger (talk) 13:11, 20 September 2015 (UTC)

I suggest grabbing a globe, a flashlight, and heading into a dark room. Put the support for the globe pointing away from you, and the light shining past your head at the globe (we'll pretend it's the Winter Solstice to make life easier).

• Light source --> You --> Globe <-- Support

From your perspective, spin the globe from left to right (that would be counter-clockwise if looking from above). Every time a city passes under the support, it becomes a new day for that city. When England passes under the support (Sunday 0:00 UTC), the Americas are still on Saturday. We won't become Sunday until we pass under the support, since we're a few hours behind. G R E E N E R 13:34, 20 September 2015 (UTC)

Yes, like I say, we know how time works. The problem is that the page is wrong, and this template needs to be extended to make it right (or we need to not use the template, but I tried that and it got edited out). -- Dagger (talk) 14:39, 20 September 2015 (UTC)

Then I'm sorry, I don't know where you're making this claim from: "It actually tells you that it's 5 PM on Sunday, then tells you that Sunday is Saturday." It doesn't, and then it doesn't. Seven hours before the start of Sunday is 5:00 PM Saturday; Sunday 00:00 UTC (17:00 UTC-7). G R E E N E R 15:17, 20 September 2015 (UTC)

(Reset indent) Hi guys. Alright I can see that being 24 hour out, if given the context "Saturday 23:00 UTC (00:00 UTC+1)" would appear wrong, but "Saturday 23:00 UTC (Sunday 00:00 UTC+1)" or "Saturday 23:00 UTC (00:00 UTC+1 next day)" would be clearer.

I'll make a proposal for the javascript to do this:

if (wgIsArticle || window.location.href.indexOf('action=submit') > - 1 || wgNamespaceNumber == - 1) {
  $(function () {
    autoConvertUTC2();
  });
}
/*
 * autoConvertUTC (see [[Template:UTC time]])
 *   by Patrick Westerhoff [poke]
 */

function autoConvertUTC2() {
  function pad(s) {
    return (s < 10 ? '0' : '') + s;
  }
  [].forEach.call(document.querySelectorAll('.utc-auto-convert2'), function (v, i) {
      var time = v.innerHTML.match(/(\d?\d):(\d\d) UTC/);
      if (!time) {
        return;
      }
      var date = new Date();
      date.setUTCHours(time[1], time[2], 0, 0);
      if (date.getTimezoneOffset() == 0) {
        v.title = 'This is your timezone';
      }
      else {
        var offset = ( - 1 * date.getTimezoneOffset() / 60);
        var local = pad(date.getHours()) + ':' + pad(date.getMinutes()) + ' UTC' + (offset < 0 ? offset : '+' + offset);
        var longformat = v.innerHTML.match(/(\w+) (\d?\d):(\d\d) UTC/);
        if (longformat) {
          var suffixText = '';
          if ( (date.getUTCHours() + offset) >= 24 ) { suffixText = ' <i>next day</i>'; }
          if ( (date.getUTCHours() + offset) <   0 ) { suffixText = ' <i>previous day</i>'; }
          local = local + suffixText;
        }
        v.innerHTML += ' (<span style="cursor: help; border-bottom: 1px dotted silver;" title="This is your timezone">' + local + '</span>)';
      }
  });
}

And some test code:

*<span class="utc-auto-convert2">22:10 UTC</span> *<span class="utc-auto-convert2">Thursday 22:10 UTC</span> *<span class="utc-auto-convert2">Thursday 23:10 UTC</span> *<span class="utc-auto-convert2">Friday 00:10 UTC</span> *<span class="utc-auto-convert2">Doesntexistday 00:10 UTC</span>

22:10 UTC Thursday 22:10 UTC Thursday 23:10 UTC Friday 00:10 UTC Doesntexistday 00:10 UTC

You can preview this code if you use, for example, the firefox scratch pad (shift+F4). "previous day" and "next day" are still gonna be ugly though. -Chieftain Alex 17:02, 20 September 2015 (UTC)

Here's a version that displays a day name:

if (wgIsArticle || window.location.href.indexOf('action=submit') > - 1 || wgNamespaceNumber == - 1) {
  $(function () { autoConvertUTC2(); });
}

function autoConvertUTC2() {
  function pad(s) {
    return (s < 10 ? '0' : '') + s;
  }
  var days = ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"];
  [].forEach.call(document.querySelectorAll('.utc-auto-convert2'), function (v, i) {
      var time = v.innerHTML.match(/(\d?\d):(\d\d) UTC/);
      if (!time) {
        return;
      }
      var date = new Date();
      date.setUTCHours(time[1], time[2], 0, 0);
      if (date.getTimezoneOffset() == 0) {
        v.title = 'This is your timezone';
      }
      else {
        var offset = (-1 * date.getTimezoneOffset() / 60);
        var local = pad(date.getHours()) + ':' + pad(date.getMinutes()) + ' UTC' + (offset < 0 ? offset : '+' + offset);
        var longformat = v.innerHTML.match(/(\w+) (\d?\d):(\d\d) UTC/);
        if (longformat) {
          var dayIndex = days.indexOf(RegExp.$1);
          if (dayIndex > -1) {
            if ((date.getUTCHours() + offset) >= 24) { dayIndex += 1; }
            if ((date.getUTCHours() + offset) <   0) { dayIndex -= 1; }
            
            if (dayIndex < 0) { dayIndex = 6; }
            if (dayIndex > 6) { dayIndex = 0; }

            local = days[dayIndex] + " " + local;
          }
        }
        v.innerHTML += ' (<span style="cursor: help; border-bottom: 1px dotted silver;" title="This is your timezone">' + local + '</span>)';
      }
  });
}

Okay, so it hardcodes the names of the week in an array (so it's English-only and requires people to be able to spell), but it seems to work fine. Only tested in UTC+1 (with Firefox scratchpad), but it should work with western timezones too. -- Dagger (talk) 20:18, 20 September 2015 (UTC)

I adjusted the code to include “the next day” or “the day before” respectively to your offset if the date changes. The solution is constructed so it does not break existing usages at all (e.g. by requiring the day now). poke | talk 07:19, 23 September 2015 (UTC)

Can you make it use the day if a day is given? I think it looks an awful lot nicer that way. (Also, sentences like "Daily reset is at 00:00 UTC (16:00 UTC-8 the previous day)" are a little weird, since it doesn't really matter which day the daily reset happens on.) -- Dagger (talk) 21:00, 23 September 2015 (UTC)

I mean, are we really sure we want pages that look like this:

or this:

or even this monstrosity:

Those suck. This template needs to take and display a day name to avoid examples like the above. I'll do the work of going through every existing use and fixing them up where needed, but I can't change the JS. --Dagger (talk) 05:00, 6 November 2015 (UTC)

Revisited

(Reset indent) I didn't realise this was still an issue until I saw a comment from July 2016 on Talk:Server reset#What about Africa?. I've come up with some simpler code that uses the mediawiki #time parser function to shortcut most of the ugly code.

Template code

<span class="utc-auto-convert3" data-time="{{#iferror:{{#time: U | {{{1|Monday 18:15 UTC}}} }}|error}}">{{{1|Monday 18:15 UTC}}}</span>

Javascript

function pad (s) {  return (s < 10 ? '0' : '') + s; }
var days = ['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday', 'Sunday'];
$('.utc-auto-convert3').each(function(i,v){

  // Get UTC time using MediaWiki {{#time: U}} epoch format
  var utcseconds = v.getAttribute('data-time');
  if (utcseconds == 'error') {
    return;
  }
  var d = new Date(0);
  d.setUTCSeconds(utcseconds);
  var offset = (-1 * d.getTimezoneOffset() / 60);
  var offsetstring = '';
  if (offset > 0) { offsetstring = '+' + offset; }
  if (offset < 0) { offsetstring = offset;       }

  // Default to showing the time only
  var datestring = pad(d.getHours()) + ':' + pad(d.getMinutes()) + ' UTC' + offsetstring;
  var titlestring = pad(d.getUTCHours()) + ':' + pad(d.getUTCMinutes()) + ' UTC';
  
  // But check for different formatting in case there is a day of the week given inside the span
  if (!v.textContent.match(/^\d/)) {
    datestring  = days[d.getDay()] + ' ' + datestring;
    titlestring = days[d.getUTCDay()] + ' ' + titlestring;
  }

  // Show result
  $(v).html('<span style="cursor:help; border-bottom:1px dotted silver;" title="'+titlestring+'">'+datestring+'</span>');
});

It converts the given date string, using any format you like as long as mediawiki's #time function understands it, into a time in seconds since the Epoch. Then you set the date in javascript as that number of seconds, and finally pull the local time out.

I haven't given it the bulletproof-ness of the common.js code, but I think it would be a good new starting point. -Chieftain Alex 18:20, 17 September 2016 (UTC)

One thing to note that some of our uses of this template need to have a day (e.g. "weekly reset at Friday 20:00"), but other uses need to not have a day ("daily reset at 18:00"), so we need some way to pick the right mode. -- Dagger (talk) 19:18, 17 September 2016 (UTC)

Adjusted slightly. Now it picks up what the text was inside the span + uses that to decide on the output format. I'm now wondering if I need to show the UTC time as well. -Chieftain Alex 22:15, 17 September 2016 (UTC)

How about something like "Weekly reset happens at Sunday 23:30 UTC-7."? That way the UTC/server time version is available on demand, but the main text shows the local time. -- Dagger (talk) 07:47, 18 September 2016 (UTC)

That working for you when previewed? (I added a bit more functionality, now it will take any given timezone in the original template parameter, e.g. "18:15 PDT", convert it to your local time, and put the UTC string in the title. -Chieftain Alex 09:40, 18 September 2016 (UTC)

It's a little buggy (now fixed). For the tooltip it was getting the hour from UTC but the day/minutes from local time. I simplified the day detection too (you used "\w{2+}" instead of "\w{2,}", but I figure it doesn't even need to be that complicated: just detecting whether the span begins with a number or not is probably good enough).

Test cases:

23:15 UTC

Monday 23:15 UTC

Monday 16:15 PDT

-- Dagger (talk) 15:50, 19 September 2016 (UTC)

Hmm I thought that the minutes would be the same for getUTCMinutes and getMinutes, but now I see there are some timezones where that is not the case (India/Nepal border at +5.75hr!). Good work.

Now the template compatibility question with the old usage cases: I've checked that World boss and Event timers use their own conversion within their widgets, so those are okay. All of the widget usage via {{UTC time}} look to be okay too. I can't think of any pages using the "utc-auto-convert" class directly. So I think we're probably good to switch the common.js and template over. -Chieftain Alex 17:37, 19 September 2016 (UTC)

Search confirms no direct uses. Once you've changed it I'll go over every page using {{UTC time}} to make sure they're using it right. -- Dagger (talk) 20:51, 19 September 2016 (UTC)

this talk section--Relyk ~ talk < 01:18, 20 September 2016 (UTC)

Yep. JS seems to have roughly nothing to help you do dates/times. :/

I've been through everything. I'm not quite sure what to do with Template:Dry Top rare creature table, and Sous-Chef Seimur Oxbone is obviously just wrong but I'm not sure what the right time is. There are also a few pages (Map bonus reward/profit, World versus World, Guild mission, Guild Merit) that would benefit from something like "at TIME on DAY" or "on DAY at TIME" format, but I'm not sure if it's worth the effort to support that. -- Dagger (talk) 21:07, 20 September 2016 (UTC)

UTC vs GMT

I noticed this is actually displaying GMT, not UTC. GMT is a timezone, and Germany, where I live we switch from GMT+1 to GMT+2 in summer. UTC is a time standard, which adjusts for DST, thus UTC+1 is the correct display, but the Wiki shows UTC+2. Asuka (talk) 15:43, 11 September 2015 (UTC)

If it should still be named UTC time the function should be more like one of these results: https://jsfiddle.net/Megumi/a4wcxk1z/ Asuka (talk) 16:17, 11 September 2015 (UTC)

Um, per this, UTC doesn't adjust for daylight savings (time standard does not change with daylight). GMT does however change.

Afaik this template is correct since any current time that I put in from the wiki clock at the top is always equal to the time on my PC... -Chieftain Alex 16:56, 11 September 2015 (UTC)

The JavaScript that drives this template uses the function getTimezoneOffset, which reads your system's clock to determine what +/- value to use. In other words, it should always convert the given UTC time into the correct time for the offset your system is set to. I'm in the Central timezone of the USA, which is normally UTC-6 but changes to UTC-5 during DST, so I see offsets of either -6 or -5 depending on the time of year (currently it's -5). —Dr Ishmael 17:24, 11 September 2015 (UTC)

@Alex: you read it the wrong way. Taking Ishmaels example: he changes his TIME ZONE from CST to CDT (which is a different time zone which has a +1 offset to the CST) he changes from GMT-6 to GMT-5, as GMT is also a TIME ZONE. UTC is a time standard which is based on GMT, but if dst is active it offsets +1 or +2 (for some countries), but still is the standard of that offset. @IshmaelCheck your Windows clock, where it's implemented correctly, it will still tell you UTC-6. Asuka (talk) 17:36, 11 September 2015 (UTC)

UTC is a standard that never changes, it's not a timezone. All timezones are defined based on UTC. CDT is a modification of CST that shifts the UTC offset by 1 hour - my Windows clock shows me the base offset for a timezone, not the DST-modified offset.

GMT is obsolete and shouldn't be used as a standard reference anymore. —Dr Ishmael 17:49, 11 September 2015 (UTC)

The only place “GMT” should be used for is to refer to the timezone in the UK when it is not observing daylight saving time. UTC is the base reference for all timezones which is why this template takes a time in UTC and then converts it to your local time which is solely based on your system’s settings (and DST is taken into account if relevant). poke | talk 14:19, 13 September 2015 (UTC)

User Preference: Time offset

It seems like Úser Preferences are entirely ignored, i. e. the function uses getTimezoneOffset and hence the time zone configured for the OS or Browser and not what the user may have configured for their GW2wiki Account.

If this is the intended behavior, the option to configure a Time offset should probably removed from the User Preferences.Necropola (talk) 06:59, 11 September 2023 (UTC)