fix: send date as string instead of epoch

[SebastianKrupinski]

Resolves: #6528

Testing Recommendation

1. Test with existing appointment schedule and fresh appointment schedule (make sure when creating a new appointment schedule the browser time zone matches the calendar time zone, as there is another bug that will affect this)
2. Test by selecting different time zones negative (North America/South America), positive (Australia/China/Etc) and matching the appointment schedule
3. Test by changing browser time zone (either override browser setting or change system time zone). You can check your browser time zone here: https://webbrowsertools.com/timezone/
4. Test by selecting time zones with an offset greater than the current time. (if the current time is 10.00 select zone that has offset of +11 hours, if the time is 14.00 select timezone that is -11 hours, this would in the past roll the date back one day)
5. Test by selecting dates close to year end and start
6. Compare all slot times to a external source I recommend https://www.worldtimebuddy.com/ or https://www.timeanddate.com/worldclock/converter.html you can preset all testing time zones and compare the times

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.

Project coverage is 23.40%. Comparing base (eb3b186) to head (91d787c).
Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
src/services/appointmentService.js	0.00%	2 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #6532      +/-   ##
============================================
- Coverage     23.41%   23.40%   -0.01%     
  Complexity      472      472              
============================================
  Files           249      249              
  Lines         11902    11901       -1     
  Branches       2282     2283       +1     
============================================
- Hits           2787     2786       -1     
  Misses         8788     8788              
  Partials        327      327              

Flag	Coverage Δ
javascript	14.84% <0.00%> (ø)
php	59.45% <ø> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[st3iny]

Now it seems to make sense. Time zones are ridiculously complicated.

I left a comment regarding the formatting in the frontend.

[st3iny]

We need proper formatting here. Month and date might only have a single digit.

Please use the getYYYYMMDDFromDate(date) from src/utils/date.js which already implements formatting as YYYY-MM-DD.

[st3iny]

import { getYYYYMMDDFromDate } from '../../utils/date.js'

// [...] further down

const selectedDay = getYYYYMMDDFromDate(this.selectedDate)

[SebastianKrupinski]

Okay,

2024-1-1 or 2024-01-01 make no difference, its the same date.

getYYYYMMDDFromDate will not work. toISOString shifts the date to UTC which changes the date in some situations, already tried toISOString.

export function getYYYYMMDDFromDate(date) {
	return new Date(date.getTime() - (date.getTimezoneOffset() * 60000))
		.toISOString()
		.split('T')[0]
}

[st3iny]

Yeah, that is why Georg implemented it in a way that reverts the shift to UTC (from the browser's local time zone). See date.getTime() - (date.getTimezoneOffset() * 60000)

I tested it with a fake time zone in Chrome and it should work correctly.

[SebastianKrupinski]

Okay, I'll change it and try it.

[SebastianKrupinski]

Yeah, I don't trust the calculation in getYYYYMMDDFromDate

Tested with:

• Value In
  Wed Nov 27 2024 14:44:54 GMT-0500 (Eastern Standard Time)

• Value produced by "new Date(date.getTime() - date.getTimezoneOffset() * 60000)"
  Wed Nov 27 2024 09:44:54 GMT-0500 (Eastern Standard Time)

As you can see it shifted the time by 5 hours. This would have the effect of shifting the date, if the input value time was less then the offset.

E.g.
Input
Wed Nov 27 2024 2:00:00 GMT-0500 (Eastern Standard Time)

Result
Wed Nov 26 2024 21:00:00 GMT-0500 (Eastern Standard Time)

Then toISOString produces this
2024-11-27T14:44:54.790Z

The end result seems correct in my browser and time zone but will this be correct for every time zone and browser. IDK

[st3iny]

I get that it is confusing. The thing is, that JavaScript's Date is not time zone aware. It always converts to the local time zone, regardless of which time zone you pass to the constructor.

We have unit tests in place to ensure that this implementation works and it is used throughout Calendar.

If it breaks we can fix it. The important thing is that we have one central implementation and not many copied across the code base because this is way harder to maintain.

[st3iny]

See also https://stackoverflow.com/a/29774197/7840137

[st3iny]

But yeah, let's not get pedantic over 3 lines of code.

Let's not get pedantic over 3 lines of code.

[ChristophWurst]

@GVodyanov could you give this a test with the instructions provided? :)

[GVodyanov]

Hey, would you be able to explain this? I'm pretty confused as to why just that Tuesday doesn't work (all other days as far as I can see are fine)

Kooha-2024-12-09-19-32-48.mp4

[SebastianKrupinski]

Hey, would you be able to explain this? I'm pretty confused as to why just that Tuesday doesn't work (all other days as far as I can see are fine)

Do you have an "all day event" on that Tuesday? That would cause the slots to be filtered out as a conflict during that time.

[GVodyanov]

Hey, would you be able to explain this? I'm pretty confused as to why just that Tuesday doesn't work (all other days as far as I can see are fine)

Do you have an "all day event" on that Tuesday? That would cause the slots to be filtered out as a conflict during that time.

I'm dumb

[SebastianKrupinski]

Do you have an "all day event" on that Tuesday? That would cause the slots to be filtered out as a conflict during that time.

I'm dumb

🤣 don't worry, I did the same thing

[ChristophWurst]

/backport to stable5.0