0

I'm trying to setup a countdown which takes a date and time entered in a backend dashboard and displays a countdown on the frontend, the countdown should be to that date across timezones, if someone is in a different timezone it should still countdown the days, hrs, mins, secs to the same time.

I am really struggling with whether the new Date() should have Z included or not, whether to use an offset and some DST concerns based on my scenario. I've tried each and got the results below, one works but I'm not 100% sure why.

In summary: How can I get this countdown script to countdown to the same date/time no matter what timezone the visitor is in. I think the answer might be in relation to being able to include the timezone offset at the time entered in the dashboard in new Date()?

See the code comments below.

function countdown() {

  var countdown = document.getElementById( 'countdown' );
  var countdownDate = new Date( '2023-06-22T22:00Z' ).getTime(); // This could be any date/time entered via backend dashboard which has 2 inputs one to select a date (stored in Y-m-d format) and one to select a time (stored in 00:00 format), this is output via <?php echo $date; ?>T<php echo $time; ?>Z, the backend dashboard has a general timezone setting which if needed can return in formats of Europe/London, UTC, +/-0:00, etc
  // If Z not on the end
    // if in UK countdown is correct
    // if in Pago Pago the countdown is to the local 10pm - I want the countdown to be to the same across timezones
 // If Z is on the end
    // if in UK countdown incorrect as 1 hour out
    // if in Pago Pago countdown incorrect as 1 hour out
// If Z not on the end and I replace with +01:00
    // if in UK countdown is correct
    // if in Pago Pago the countdown is correct (same countdown as UK)
    
// BUT i'm unsure exactly why +01:00 seems to work I think this is because I am currently in a +01:00 time zone and I entered the dates in the admin area when timezone was +01:00, it seems like this would cause issues in future relating to DST
 
// Note that I am testing Pago Pago using Chrome DevTools > Sensors > Location
 
  var x = setInterval( function() {

    var now = new Date().getTime();
    var distance = countdownDate - now;

    if ( distance < 0 ) {

      clearInterval( x );
      countdown.remove();

    } else {

      var days = Math.floor( distance / ( 1000 * 60 * 60 * 24 ) );
      var hours = Math.floor( ( distance % ( 1000 * 60 * 60 * 24 ) ) / ( 1000 * 60 * 60 ) );
      var minutes = Math.floor( ( distance % ( 1000 * 60 * 60 ) ) / ( 1000 * 60 ) );
      var seconds = Math.floor( ( distance % ( 1000 * 60 ) ) / 1000 );

      var text = '';
      text += days + ' days ';
      text += hours + ' hours ';
      text += minutes + ' minutes ';
      text += seconds + ' seconds ';

      countdown.innerHTML = text;

    }

  }, 1000 );

}

countdown();
<div id="countdown"></div>
bigdaveygeorge
  • 947
  • 2
  • 12
  • 32
  • All javascript dates are stored as UTC which represents a moment in time independent of its representation in any given timezone. Whether you choose to create the date using a specific offset or not has no bearing on the moment stored. – pilchard Jun 22 '23 at 10:24
  • @pilchard would I be correct to leave the Z on the end of the new Date()? That appears to return the countdown the same across timezones but it is 1 hour out, how do I deal with that issue? Is the "now" variable correct, I feel like that might need an offset...? – bigdaveygeorge Jun 22 '23 at 10:34
  • `var countdownDate = new Date( '2023-06-22T22:00Z' ).getTime();` - why output a _formatted_ date to the client, only to then parse it and get the milliseconds - instead of having your PHP code _directly_ output the DateTime object you got, formatted as milliseconds? https://stackoverflow.com/a/67978825/1427878 – CBroe Jun 22 '23 at 10:53
  • @CBroe I have just tried that, but the 1 hour out issue still remains...? – bigdaveygeorge Jun 22 '23 at 11:03
  • Re `new Date( '2023-06-22T22:00Z' ).getTime()` consider `Date.parse('2023-06-22T22:00Z')` which produces an identical result without creating a *Date* object. The resulting time value is timezone independent (it's UTC). The hour difference you see is likely because you're comparing to British Summer Time (BST). The equivalent instant in BST is 2023-06-22T23:00+01:00. – RobG Jun 22 '23 at 11:04
  • @CBroe Using either of those https://jsfiddle.net/5yfknwmu/ I still have the hour out issue. Rob/Cbroe what do I need to do to this code (and/or the saving of the date/time in the admin dashboard) to ensure the countdown takes the offset into account so the countdown is to the entered date/time regardless of timezone? – bigdaveygeorge Jun 22 '23 at 11:11
  • _"I have just tried that, but the 1 hour out issue still remains...?"_ - then presumably what you have stored in your DateTime on the server side, is off by one hour already. You say you have "a date and time entered in a backend", so how exactly are you handling those? What timezone _are_ you using? – CBroe Jun 22 '23 at 11:17
  • @CBroe The time is entered via a HTML time field and stores the data as 00:00, the date gets stored in format 2023-06-22, I am in the UK timezone. So if i've set the countdown to be to on a date at 10pm I want it to countdown to 10pm, when the clocks change for DST I still want the countdown to be to 10pm. I think it might be because when the date is output it's run through gmdate()... in PHP? – bigdaveygeorge Jun 22 '23 at 11:26
  • @CBroe Ignore the last part about gmdate, I got that wrong. – bigdaveygeorge Jun 22 '23 at 11:39

0 Answers0