问题
I am using momentjs to check difference in minutes between two time stamps of a train trip. The API that I'm using to grab the data from returns times in 24 hours format (momentjs: HH:mm:ss).
If the trip continues to the next day, the time is shown as, for example, "24:12:00" which is pretty weird. Momentjs can't deal with this, and if I try to calculate time difference with such values I get "NaN".
So I created a function to convert any "24" occurrence to "00".
function maintainHour (timeString) {
var splitted = timeString.split(':');
if(splitted[0] == '24') {
splitted[0] = '00';
}
return splitted[0] + ':' + splitted[1] + ':' + splitted[2];
}
If I use the diff() function to check difference between one timestamp and a timestamp that has "00" as hour, I cannot differ whether it's a timestamp within the current day or the next day. So difference will be something around -900 if current time is 16:00 for example (meaning the morning of this day) rather than positive X minutes until 24h of the upcoming day.
Any idea how to deal with this?
回答1:
Because you are dealing with just a time, you're going to have problems like this. When you deal with just a time, moment assumes the current day when parsing. Of course, when you set those hours back to zero, you get the problem you are describing - the end time is earlier than the start.
This is un-intuitive, but I would maybe actually use the 'overflow' capabilities of set to resolve this issue.
When you pass a value to a moment set function (.hours(), .minutes(), etc), if the value exceeds the allowable range, it will overflow into the next unit. You can use that to your advantage here. Split the later time (the one that could potentially have the 24), as you are. Then do something like this:
moment.utc('2016-01-01')
.set({hours:splitted[0], minutes:splitted[1], seconds:splitted[2]}).format()
As a concrete example of what happens:
moment.utc('2016-01-01').set({hours:24, minutes:32, seconds:12}).format()
"2016-01-02T00:32:12Z"
As you can see, 24 pushed it into the next day.
It sounds like all you have here are times, not dates. If that is correct, then I strongly suggest picking an arbitrary date as your parse date, and using UTC mode for your moments.
If you use moment in local mode with an arbitrary date, you could potentially run into issues where differences are not what you expect due to DST transitions. In UTC mode, those don't happen.
It is worth noting that conversely, if you DO know the date, you should use it, and in the correct time zone (with moment timezone if necessary), so that you do capture DST transitions that may cause the difference in hours to vary between the same two times.
In addition, setting the date manually avoids a possible race condition where the first invocation of moment lands on a different date than the second invocation of moment. That's a bug that will be super hard to find later.
来源：https://stackoverflow.com/questions/36811502/moment-js-24-hour-time-format-dealing-with-the-24th-hour