Solve time zone problems

[Sybrand]

Describe the task We keep having issues with dates and times in frontend tickets. To solve this once and for all, create some date class that encapsulates the issues with timezones and date arithmetic.

Acceptance Criteria

• [ ] All devs are happy
• [ ] No confusion when selecting a date (as in 22 October 2022)
• [ ] No confusion when selecting a date and time (as in 22 October 2022 22h22.22 +2GMT)
• [ ] No confusion over #$%$$ time zones
• [ ] Clear interface for creating the object based on the native javascript Date object
• [ ] Clear interface for creating the object based on iso formatted date strings
• [ ] Clear interface for adding and subtracting days
• [ ] Well tested (Aim for ~90% test coverage?, 100% if possible)
• [ ] PST/PDT as the initial policy for time

Additional context

• Take a look as date-fns for handling date algebra in this date wrapper class: https://date-fns.org
• https://app.zenhub.com/workspaces/bcws---agile-psu-5e321393e038fba5bbe203b8/issues/gh/bcgov/wps/2663

Maybe something that looks like this:

export class SmartDate {
  /**
   * I propose we use a class that looks like this for all internal represenation of dates.
   * The idea is, that when dealing with this object, you never have to worry about
   * time zones.
   * We happen to represent the date internally using the luxon DateTime object,
   * but that's none of your business.
   */
  private _date: DateTime

  private constructor(date: DateTime) {
    this._date = date
  }

  static fromISODateString(isoDate: string): SmartDate {
    /* Given a date in the format YYYY-MM-DD return a smart date object.

    How we store the object is none of your business. */

    // setZone: true is very important here. We're telling DateTime not to use the local timezone,
    // and to just stick to the offset we've given it. This helps us avoid weird bugs where
    // converting to and fro between iso strings and date objects results in date changes due
    // to timezones. (e.g. the 14th of July in PST could be the 15th of July in UTC depending on
    // the time of day.)
    return new SmartDate(DateTime.fromISO(isoDate + 'T00:00+00:00', { setZone: true }))
  }

  static fromJSDate(jsDate: Date): SmartDate {
    /* Given a JS Date object return a smart date object - we don't care what timezone
    you're in, or what time it is. If you say it's June the 5th, you'll get June the 5th
    back. We throw away the time part of the date, and we throw away the timezone part.

    What we store it as internally is none of your business. */
    return SmartDate.fromISODateString(jsDate.toISOString().substring(0, 10))
  }

  public plus(duration: DurationLike): SmartDate {
    return new SmartDate(this._date.plus(duration))
  }

  public toISODateString(): string {
    /* Return an ISO date string in the format 'YYYY-MM-DD'.
    There is no time, or zone information - you asked for a date, and that's what you get.
    You get what you get and you don't get upset!
    */
    return this._date.toISODate()
  }
}

[Sybrand]

Hey team! Please add your planning poker estimate with ZenHub @andrea-williams @conbrad @JulianForeman

[BAAlexK]

Hey team! Please add your planning poker estimate with Zenhub @brettedw @dgboss