I am validating the date and time with moment().isValid(), but the date and time validation at 24:00:00 does not work as expected.
console.log(moment('2020-07-02 24:00:00','YYYY-MM-DD HH:mm:ss',true).isValid());
I want the result of the above code to be false, but the actual behavior is true.
How can I implement the above phenomenon to get the expected result?
We also conducted tests on parts that seemed to be related, but the behavior at 60 minutes, 60 seconds, etc. was as expected.
// 24:00:00
console.log(moment('2020-07-02 24:00:00').isValid()); //true
console.log(moment('2020-07-02 24:00:00','YYYY-MM-DD HH:mm:ss').isValid()); //true
console.log(moment('2020-07-02 24:00:00','YYYY-MM-DD HH:mm:ss',true).isValid()); //true (Unexpected)
console.log(moment('2020-07-02 24:00:00','YYYY-MM-DD hh:mm:ss',true).isValid()); //false
console.log(moment('2020-07-02 24:00:00','YYYY-MM-DD kk:mm:ss',true).isValid()); //true
// other
console.log(moment('2020-07-02 24:00:01','YYYY-MM-DD HH:mm:ss',true).isValid()); //false
console.log(moment('2020-07-02 24:01:00','YYYY-MM-DD HH:mm:ss',true).isValid()); //false
console.log(moment('2020-07-02 23:58:60','YYYY-MM-DD HH:mm:ss',true).isValid()); //false
console.log(moment('2020-07-02 23:59:60','YYYY-MM-DD HH:mm:ss',true).isValid()); //false
console.log(moment('2020-07-02 22:60:00','YYYY-MM-DD HH:mm:ss',true).isValid()); //false
console.log(moment('2020-07-02 23:60:00','YYYY-MM-DD HH:mm:ss',true).isValid()); //false
console.log(moment('2020-07-02 23:60:60','YYYY-MM-DD HH:mm:ss',true).isValid()); //false
It seems caused by following issue:
Is there any workaround for handle datetime format as "24:00" #1174 - moment/moment
In ISO 8601, Midnight is a special case and can be referred to as both "00:00" and "24:00" (Midnight day after and Midnight today so to speak). While it should not technically "bubble", it is perfectly valid.
As a supplement, current spec does not seem to permit it:
Midnight is a special case and may be referred to as either "00:00" or "24:00", except in ISO 8601-1:2019 where "24:00" is no longer permitted.
Related
The code:-
moment(moment("2022-12-12").format("YYYY-MM-DD"), "YYYY-MM-DD", true).isValid()
returns true as 2022-12-12 is a valid date in YYYY-MM-DD format.
Using the same logic, I tried to check if var timeString = "16:00:00" is a valid time or not.
However, the following code:-
moment(moment("16:00:00").format("HH:mm:ss"), "HH:mm:ss", true).isValid()
always gives me false.
What am I doing wrong?
It's always giving true as you are formatting to that particular type first than checking if its valid which is why its always true.
I think you want something like this.
function isTimeFormat(time) {
return moment(time, 'HH:mm:ss', true).isValid();
}
I'm confused.
I have a textbox that is populated with a date and time (string) such as '09/07/2021 10:30'.
I convert this string to a moment like so:
var suggestedDateObj = moment(suggestedDate, 'DD/MM/YYYY HH:mm');
I then want to check if this date and time is in between time slots in a fullcalendar.js event object. I do this like so:
var startDateObj = moment(value.start);
var endDateObj = moment(value.end);
if (suggestedDateObj.isBetween(startDateObj, endDateObj)) {}
However...it isn't working. And it's due to timezone offset (i think).
suggestedDateObj returns a value with a UTC offset of +0100 (British Summer Time)
However my calendar event objects return a date with a UTC offset of +0000. So when i check if '09/07/2021 10:30 +0100' is in between '09/07/2021 10:30 +0000' and '09/07/2021 11:30 +0000' it doesn't work!
I guess my question is really either:
How can I create my suggestedDateObj moment with a timezone offset of zero? OR
How can i tell fullcallendar events that the time it is displaying is actually BST (+0100)? At the moment I don't specify the 'Timezone' parameter.
Thanks.
UPDATE
Hmm....this might work....although it feels a bit clunky:
var tmoment1 = moment(suggestedDate, 'DD/MM/YYYY HH:mm');
//create default date with specific timezone offset of zero
var suggestedDateObj = moment().utcOffset(0);
//set the date and time
suggestedDateObj.set({
day: tmoment1.day(),
month: tmoment1.month(),
year: tmoment1.year(),
hour: tmoment1.hour(),
minute: tmoment1.minute(),
second: 0
});
You can generate suggestedDateObj in utc like that:
var suggestedDateObj = moment.utc(suggestedDate, 'DD/MM/YYYY HH:mm');`
For the .isBetween() I suggest you to use the square bracket like forth parameter, like documentation says.
if (suggestedDateObj.isBetween(startDateObj, endDateObj, undefined, '[]'))
The square brackets indicate that the check must include the dates of the limiter
We have an address, that according to momentjs is reporting as valid.. any thoughts?
You can see the behavior in this fiddle
var wrong_date = "7840 W HICKS STREET";
document.write(moment(wrong_date, "YYYY-MM-DD HH:mm:ss").isValid()); //returns true
https://jsfiddle.net/jeffbeagley/2c9urj5v/1/
Use strick format parsing:
var wrong_date = "7840 W HICKS STREET";
document.write(moment(wrong_date, "YYYY-MM-DD HH:mm:ss", true).isValid());
Notice the third boolean parameter set to true.
This is a strick match on the format.
Moment's parser is very forgiving, and this can lead to undesired behavior. As of version 2.3.0, you may specify a boolean for the last argument to make Moment use strict parsing. Strict parsing requires that the format and input match exactly, including delimeters.
document.write(moment(wrong_date, "YYYY-MM-DD HH:mm:ss").isValid()); //returns true
document.write(moment(wrong_date, "YYYY-MM-DD HH:mm:ss", true).isValid()); //returns false
You can use both locale and strictness.
moment('2012-10-14', 'YYYY-MM-DD', 'fr', true);
Moment API isValid seems only support format 'L' for local is 'en':
locale set to 'en':
moment(new Date()).locale('en').format('L') //"04/27/2016"
moment('04/27/2016', 'L', true).isValid() //true
local set to 'zh-cn':
moment(new Date()).locale('zh-cn').format('L') //"2016-04-27"
moment('2016-04-27', 'L', true).isValid() //false, why here is false?
As i don't want to hard code 'MM-DD-YYYY' for 'zh-cn' here, is there any other good way?
Setting the locale like that only affects the current instance of moment, not any future instances. Future instances use the default locale again, which in your case means 'L' is not the YYYY-MM-DD format.
You can either set the locale globally:
moment.locale('zh-cn');
moment(new Date()).format('L') // 2016-04-27
moment('2016-04-27', 'L', true).isValid() // true
Or specify the locale for each instance, including the one you use for parsing:
moment(new Date()).locale('zh-cn').format('L') // 2016-04-27
moment('2016-04-27', 'L', 'zh-cn', true).isValid() // true
My code looks like this
std::string date = "04/05/2015 02:07";
std::string format = "MM/dd/yyyy HH:mm";
QDateTime dateTime = QDateTime::fromString(date.c_str(), format.c_str());
bool isItValid = dateTime.isValid();
This is part of a function I have but I narrowed the problem to specifically that value for date. After executing, isItValid is false. Why is it not a valid date?
However, if I try
bool isItValid = dateTime.date().isValid() && dateTime.time().isValid();
the value is true.
Can anyone point out what's the problem with that date? what am I missing?
The documentatation of isValid() (http://doc.qt.io/qt-5/qdatetime.html#isValid) says:
Returns true if both the date and the time are valid and they are
valid in the current Qt::TimeSpec, otherwise returns false.
If the timeSpec() is Qt::LocalTime or Qt::TimeZone then the date and
time are checked to see if they fall in the Standard Time to Daylight
Time transition hour, i.e. if the transition is at 2am and the clock
goes forward to 3am then the time from 02:00:00 to 02:59:59.999 is
considered to be invalid.
So it seems it's the Qt::TimeSpec you are missing.