1

I am trying to write a function that will take a string like 07/2020 and then return whether it is more than three months away.

I have written a function isMoreThan3MonthsHence that I am reasonably sure works correctly:

const isMoreThan3MonthsHence = ({ utcYear, utcMonth }, 
                                now = new Date, 
                                target = new Date(Date.UTC(utcYear, utcMonth)), 
                                threeMonthsAway = new Date(now.valueOf()).setUTCMonth(now.getUTCMonth() + 3)) => 
    (target > threeMonthsAway)


console.log(isMoreThan3MonthsHence({ utcYear: 2020, utcMonth: 7 })) // true (correct!)

The problem comes when I try to construct a Date object to use to populate the arguments for isMoreThan3MonthsHence. 

const validate = (str, 
                  [localMonth, localYear] = str.split('/'), 
                  date = new Date(+localYear, (+localMonth)-1)) => 
    isMoreThan3MonthsHence({ utcYear: date.getUTCFullYear(), utcMonth: date.getUTCMonth() })

// Note: input is one-based months
console.log(validate('07/2020')) // false (but should be true!)

I think the reason is that new-ing up a Date in validate without specifying the timezone will use the local timezone in effect at the supplied date, which will be BST (UTC+1).

Wed Jul 01 2020 00:00:00 GMT+0100 (British Summer Time)

This time is actually 2300hrs on June 30th in UTC. So the month is actually 5 in zero-based terms. But I don't want this behavior. I want it so specifying July actually means July in UTC.

How can I fix this?

Ben Aston
  • 53,718
  • 65
  • 205
  • 331
  • Perhaps because `Date.UTC()` treats your arguments as UTC, while `new Date()` treats them as local (UTC+1) and once you're calling `getUTCMonth()` you're indeed an hour earlier from UTC perspective (then still in the previous month). Why not use `Date.UTC()` in both? – haim770 Mar 03 '20 at 16:41
  • Do `new Date(2020, 6).toUTCString()` - i.e. looking at the entire date, not just month and year - and you will clearly see why. Yes, it does have to do with the fact that you're in BST in July. – Bergi Mar 03 '20 at 16:42

2 Answers2

2

It looks like you're mixing the usage of Date.UTC and not when instantiating dates. For example, if you use the following for your validate function:

const validate = (str, 
                  [month, year] = str.split('/'), 
                  date = new Date(Date.UTC(+year, (+month)-1))) => 
    isMoreThan3MonthsHence({ utcYear: date.getUTCFullYear(), utcMonth: date.getUTCMonth() })

// Note: input is one-based months
console.log(validate('07/2020')) // Now true

It works as expected: JSFiddle

Removing the usage of Date.UTC altogether would perform the calculation in the user's local timezone, with any applicable daylight saving adjustment included. This could be seen as a valid approach, however would result in the behaviour you have described.

Note I've renamed the local prefixed variables based on feedback from Bergi. Using Date.UTC implies you're passing in UTC arguments.

Oliver
  • 8,794
  • 2
  • 40
  • 60
1

Other than mixing UTC and local dates, the way you're adding 3 months will cause an incorrect response for dates like 31 March, where adding 3 months simply by incrementing the month number results in a date for 1 July. See Adding months to a Date in JavaScript.

So validate('07,2020') will return false if run on 31 March.

To fix that, when adding months, check that the updated date is still on the same day in the month, otherwise it's rolled over so set it to the last day of the previous month.

function validate(s) {
  let testDate = addMonths(new Date(), 3);
  let [m, y] = s.split(/\D/);
  return testDate < new Date(y, m-1);
};

function addMonths(date, months) {
  let d = date.getDate();
  date.setMonth(date.getMonth() + +months);
  // If rolled over to next month, set to last day of previous month
  if (date.getDate() != d) {
    date.setDate(0);
  }
  return date;
}

// Sample
console.log('On ' + new Date().toDateString() + ':');
['07/2020', '04/2020'].forEach(
  s => console.log(s + ' - ' + validate(s))
);
RobG
  • 142,382
  • 31
  • 172
  • 209