Freecodecamp: Certificate displays incorrect date

[nhcarrigan]

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.

[raisedadead]

Is this reproducible locally?

[vkWeb]

@raisedadead when Date constructor is called on the server-side it outputs date in UTC, right?

[ojeytonwilliams]

@vkWeb timezones are tricky, but the server creates a Date object and then stores that. There's no timezone information stored with it, so the date sent back is just format(new Date(completedDate), 'MMMM D, YYYY') i.e. the UTC date.

[vkWeb]

@ojeytonwilliams Indeed - timezones are tricky. Thanks for confirming that datetime given back by Node is in UTC.

https://github.com/freeCodeCamp/freeCodeCamp/blob/511238d36e296378d454ac057c000afc2ebf3c5e/api-server/server/boot/certificate.js#L551

I saw the above code just now. You are absolutely correct @ojeytonwilliams.

I looked at @nhcarrigan's GitHub profile, he lives in USA. Timezone of USA is UTC -4 hours.

What I think might be the case here is that @nhcarrigan 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 @nhcarrigan? Do you remember at what time you claimed the cert?

What do you think about all this @ojeytonwilliams?

[RandellDawson]

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).

[nhcarrigan]

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.

[vkWeb]

@RandellDawson oh my god. Timezones are actually complex.

@nhcarrigan 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?

[raisedadead]

We should be able to allow users to set a timezone in their user profiles for the correct offset.

[Sky020]

Is this in line with what we are wanting:

Or, would something more explicit be necessary?

[raisedadead]

Or, would something more explicit be necessary?

Something more along the lines of the snippet here:
https://www.freeformatter.com/time-zone-list-html-select.html

[Sky020]

@raisedadead , 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?

[ojeytonwilliams]

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.

[raisedadead]

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.

[Sky020]

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.