A date like: 2023-05-07 24:00:01 can be selected by incrementing the second, which is invalid
njmkramer opened this issue · comments
Prerequisites
- I have searched for duplicate or closed issues.
- I have validated my setup against the latest version on StackBlitz.
- I have read the contributing guidelines.
Describe the issue
A date like: 2023-05-07 24:00:01 can be selected by incrementing the second, which is invalid
StackBlitz fork
https://stackblitz.com/edit/js-hsrg9h?file=index.js
What operating system(s) are you seeing the problem on?
Windows
What browser(s) are you seeing the problem on?
Chrome
What version of are you using? You can find this information from the sample StackBlitz.
v6.7.7
What your browser's locale? You can find this information from the sample StackBlitz.
'en-GB'
Also, if you change the 24:00:00 in the stackbliz to 00:00:00, tempus will change that to 24:00:00. Which is not the same time, its 24 hours later.
This test seems to be false:
tempus-dominus/test/datetime.test.ts
Line 290 in efba21a
If the hour is 00:00 it is the beginning the current day, not 24:00 of the current day. 24:00 is the 00:00 of the next day.
I someone would ever set 24:00 as the time, tempus should reformat that to 00:00 and add 1 to the day. (or just fail, because 24:00 is not used, the clock jumps from 23:59 to 00:00)
vice-versa, a time of 00:00 is literally 00:00, so the test should read
expect(dt.getHoursFormatted('h24')).toBe('00');
This test seems to be false:
tempus-dominus/test/datetime.test.ts
Line 290 in efba21a
If the hour is 00:00 it is the beginning the current day, not 24:00 of the current day. 24:00 is the 00:00 of the next day.
I someone would ever set 24:00 as the time, tempus should reformat that to 00:00 and add 1 to the day. (or just fail, because 24:00 is not used, the clock jumps from 23:59 to 00:00)
vice-versa, a time of 00:00 is literally 00:00, so the test should read
expect(dt.getHoursFormatted('h24')).toBe('00');
Hi there.
I think you wouldn't face this if you use 'h23' instead of 'h24'.
That seems tot be correct, yes. Both 24:00 and 00:00 are valid. There is of course a wikipedia page about this issue: https://simple.m.wikipedia.org/wiki/24-hour_clock
Sorry to have hijacked this issue.
The problem of 24:01 still exists then.
On second thought, it's a bit more complex.
in h24
00:00 == 00:00 the beginning of the day
24:00 == 24:00 the end of the day
In both cases the day does not change. In h11, h12 and h23, 24:00 should either fail, or reformat to 00:00 the next day.
In the stackbliz, days are added when using 00:00 and 24:00 in all LocaleHourCycleKey's. But quite inconsequential.
so, there should be more tests:
dt.date = 8;
dt.month = 5;
dt.hours = 0;
expext(dt.dateFormatted).toBe('05'); // This seems to fail in the stackbliz at the moment, it is adding up to 2 days, depending on LocaleHourCycleKey )
expect(dt.getHoursFormatted('h24')).toBe('00');
dt.hours = 24;
expect(dt.getHoursFormatted('h11')).toFail(); // Not sure about syntax here
expect(dt.getHoursFormatted('h12')).toFail();
expect(dt.getHoursFormatted('h23')).toFail();
expect(dt.getHoursFormatted('h24')).toBe('24');
Fixed it by using 'h23' instead of 'h24'.
24:01 is still invalid
When a server time (windows) of 00:00:00 is set to the control on load, it becomes 24:00:00. This value is not valid in c#, so the control cannot write back a value that it was given, without even using the control to edit it.
