Moment.js 24小时时间格式，处理第24小时

我正在使用momentjs来检查火车旅行的两个时间戳之间的分钟差异。我使用的API以24小时制格式返回时间（momentjs：HH：mm：ss）。Moment.js 24小时时间格式，处理第24小时

如果行程继续到第二天，则时间显示为例如“24:12:00”，这很奇怪。 Momentjs无法处理这个问题，如果我尝试用这些值计算时间差异，我会得到“NaN”。

所以我创建了一个函数来将任何“24”出现转换为“00”。

function maintainHour (timeString) { 
    var splitted = timeString.split(':'); 
    if(splitted[0] == '24') { 
    splitted[0] = '00'; 
    } 

    return splitted[0] + ':' + splitted[1] + ':' + splitted[2]; 
}

如果我使用diff()功能，一个时间戳，并有“00”作为一个小时之间的时间戳检查不同，我无法区别它是否是当天或次日内的时间戳。因此，如果当前时间是16:00（例如今天上午），而不是正X分钟，直到即将到来的一天的24小时，那么差异将在-900左右。

任何想法如何处理这个？

来源

2016-04-23 Ariel Weinberger

因为你只是在处理一段时间，所以你会遇到这样的问题。当你处理一段时间时，时刻会假定当前分析的那一天。当然，当你将这些时间设置回零时，你会遇到你所描述的问题 - 结束时间早于开始时间。

这是不直观的，但我可能实际上使用set的'overflow'功能来解决这个问题。

当您将某个值传递给时刻设定功能（.hours(),.minutes()等）时，如果该值超出允许范围，则会溢出到下一个单位。你可以在这里使用你的优势。按照原样拆分较晚的时间（可能有24个的时间）。然后做这样的事情：

moment.utc('2016-01-01') 
.set({hours:splitted[0], minutes:splitted[1], seconds:splitted[2]}).format()

至于发生了什么具体的例子：

moment.utc('2016-01-01').set({hours:24, minutes:32, seconds:12}).format() 
"2016-01-02T00:32:12Z"

正如你可以看到，24推到第二天。

这听起来像你在这里所有的是时间，而不是日期。如果这是正确的，那么我强烈建议选择一个任意日期作为您的解析日期，并使用UTC模式作为您的时刻。

如果您在本地模式下使用任意日期的时间，则可能会遇到由于DST转换而导致差异不符合预期的问题。在UTC模式下，这些不会发生。

值得一提的是相反的，如果你不知道的日期，你应该使用它，并在正确的时区（与时刻时区，如果需要的话），这样你就捕捉DST转换可能导致差异小时在相同的两次之间变化。

此外，手动设置日期可避免第一次调用时间落在与第二次调用时间不同的日期时可能出现的竞争状况。这是一个稍后难以发现的错误。

来源

2016-04-23 13:49:07

我一定会试试这个。 –

Moment.js 24小时时间格式，处理第24小时

回答

相关问题