Change:
import { Observable } from 'rx'; import debug from 'debug'; import { isEmail } from 'validator'; <del> import format from 'date-fns/format'; </del> import { reportError } from '../middlewares/sentry-error-handler.js'; import { ifNoUser401 } from '../utils/middleware';

Discussion:
Describe the bug New certificate displays incorrect date. To Reproduce Steps to reproduce the behavior: I can't say I'm really sure of the steps - I claimed the certificate just a few moments ago, and it is still 3 July 2020 local time. The certificate shows "Issued July 4, 2020" however. Expected behavior Certificate earned date should be based on local time? Screenshots ! Desktop (please complete the following information): OS: Windows 10 v. 1909 Browser: Chrome Version: 83.0.4103.116 Additional context The Quality Assurance certification had no such issue.
Is this reproducible locally?
when Date constructor is called on the server-side it outputs date in UTC, right?
timezones are tricky, but the server creates a object and then stores that. There's no timezone information stored with it, so the date sent back is just i.e. the UTC date.
Indeed - timezones are tricky. Thanks for confirming that datetime given back by Node is in UTC. I saw the above code just now. You are absolutely correct I looked at GitHub profile, he lives in USA. Timezone of USA is UTC -4 hours. What I think might be the case here is that might have claimed the certificate after 3 July 2020 8:00 PM. Adding four hours to 3 July 2020 8:00 PM brings it in UTC timezone which gives us date of 4 July 2020. Can you confirm this Do you remember at what time you claimed the cert? What do you think about all this
There are 3 time zones (PST, CST - GMT-6, EST ) in the mainland US or 5 times zone if you include Alaska (GMT-8) and Hawaii (GMT-10). It also depends on the time of year, because of DST (Daylight Savings Time).
I am in the Pacific Timezone, which is currently PDT (due to Daylight Savings Time). I claimed the certificate in question at approximately 17:18 PTD, which translates to 00:18 UTC (pushing the time into the next day). This may be the source of that bug.
oh my god. Timezones are actually complex. Amazing - I believe we have found the source of this bug.

IMO, the best solution to this issue will be to append "UTC" to the issued date to make things clear for users. Going after local time will involve getting timezone from users via settings and then querying db for their timezone while claiming cert. This'll be bad in terms of UX as well as perf. So, let's add UTC at the end of issued date... what do you all think?
We should be able to allow users to set a timezone in their user profiles for the correct offset.
Is this in line with what we are wanting: ! ! Or, would something more explicit be necessary?
Something more along the lines of the snippet here:
, Would it be beneficial for a JSON file to be made in the api-server directory, in case the values need to be referenced elsewhere in the platform?
Even if they're only used in one place, it would be better to have the data imported from a separate file. It's just less cluttered that way.
Just so its clear about the implementation, we will need to store the timezone on the user record, and do any computation of the display on the client only.
Just so its clear about the implementation, we will need to store the timezone on the user record, and do any computation of the display on the client only. Thank you, for this clarification. Makes it easier, I suppose.