이것은 원래 순간/순간-시간대#327로 보고되었습니다.

2749는 관련이 있지만 약간 다릅니다.

하루의 정확한 시간을 계산하는 것과는 반대로 다음과 같이 할 수는 없습니다.

moment('2016-10-16').startOf('day').add(1, 'day').startOf('day').subtract(1, 'millisecond').format()
"2016-10-16T23:59:59-02:00"

16일에도 푸시할 때 15일에도 잘 작동합니다.

moment('2016-10-15').startOf('day').add(1, 'day').startOf('day').subtract(1, 'millisecond').format()
"2016-10-15T23:59:59-03:00"

내가 생각하지 못한 엣지 케이스가 있습니까?

다르게 하면 성능상의 이점이 있을 수 있다고 생각하지만, 읽을 수 있습니다!

흠, 여기에 또 다른 문제가 있습니다.

moment.tz("2016-10-16","America/Sao_Paulo").startOf('day').add(1,'day').startOf('day').subtract(1,'ms').format()
// "2016-10-16T23:59:59-02:00"  (ok)

moment.tz("2016-10-15","America/Sao_Paulo").startOf('day').add(1,'day').startOf('day').subtract(1,'ms').format()
// "2016-10-14T23:59:59-03:00"  (wrong date)

moment.tz("2016-10-15","America/Sao_Paulo").startOf('day').add(1,'day').format()
// "2016-10-15T23:00:00-03:00"  should have skipped forward to "2016-10-16T01:00:00-02:00"

여기에서 전체 모호한 브라우저 동작을 처리하고 있습니까? 아니면 뭔가 더 있나요?

Brasillia의 Windows 시간대가 있는 크롬:

moment("2016-10-15").startOf('day').format()
"2016-10-15T00:00:00-03:00"
moment("2016-10-15").startOf('day').add(1, 'day').format()
"2016-10-16T01:00:00-02:00"

Moment Timezone을 사용하는 내 시간대의 크롬:

moment.tz("2016-10-15","America/Sao_Paulo").startOf('day').format()
"2016-10-15T00:00:00-03:00"
moment.tz("2016-10-15","America/Sao_Paulo").startOf('day').add(1, 'day').format()
"2016-10-15T23:00:00-03:00"

멋있는!

순간 시간대에 문제가 있습니까? 제가 그 코드를 잘 몰라서 말씀드리기 어렵습니다. 첫 번째가 작동하면 브라우저처럼 보이지 않습니다.

나는 이것이 해당 날짜에 '추가'된 경우 순간 시간대가 항상 잘못된 날짜를 다시 푸시한다는 사실의 결과라고 생각합니다. 의도한 것인지 우연한 것인지 확실하지 않습니다.

//setting moves forward
moment.tz("2016-10-16T00:00:00","America/Sao_Paulo").format()
"2016-10-16T01:00:00-02:00"
//adding moves backward
moment.tz("2016-10-15T00:00:00","America/Sao_Paulo").add(1, 'day').format()
"2016-10-15T23:00:00-03:00"

//setting moves forward
moment.tz("2016-03-13T02:00:00","America/Chicago").format()
"2016-03-13T03:00:00-05:00"
//adding moves backward
moment.tz("2016-03-12T02:00:00","America/Chicago").add(1, 'day').format()
"2016-03-13T01:00:00-06:00"

//one more time for funzies
moment.tz("2016-03-27T01:00:00","Europe/London").format()
"2016-03-27T02:00:00+01:00"

moment.tz("2016-03-26T01:00:00","Europe/London").add(1, 'day').format()
"2016-03-27T00:00:00Z"

나는 이것이 시간을 지킬 수 없을 때 keepTime 설정을 사용하려고 시도하는 것과 관련이 있다고 생각합니다. 나는 이 코드가 왜 그런 것인지 말할 만큼 이 코드를 잘 알지 못하지만, 이 코드의 keepTime 호출이 1이 아닌 0이라면 모든 것이 예상대로 진행될 것이라는 것을 확실히 알고 있습니다. 뒤로 미루는 것은 시간을 유지하기 때문입니다. 그리고 시간을 유지해야 합니다. 이 엣지 케이스에서는 펑키합니다.

    moment.updateOffset = function (mom, keepTime) {
        var zone = moment.defaultZone,
            offset;

        if (mom._z === undefined) {
            if (zone && needsOffset(mom) && !mom._isUTC) {
                mom._d = moment.utc(mom._a)._d;
                mom.utc().add(zone.parse(mom), 'minutes');
            }
            mom._z = zone;
        }
        if (mom._z) {
            offset = mom._z.offset(mom);
            if (Math.abs(offset) < 16) {
                offset = offset / 60;
            }
            if (mom.utcOffset !== undefined) {
                mom.utcOffset(-offset, keepTime);
            } else {
                mom.zone(offset, keepTime);
            }
        }
    };

나는 여기에서 도움이 될 순간 시간대에 대해 충분히 알지 못하지만 아마도 keepTime 가 사용되는 이유에 대한 티켓은 조사하는 모든 사람에게 도움이 될 것입니다: https://github.com/moment/moment-timezone/ 문제/28

https://github.com/moment/moment/pull/1564

이것은 순간에 처리 영역의 마지막 큰 변경입니다. 이 문제와 관련이 있는지 확실하지 않지만 도움이 될 것입니다.

@maggiepint 설명 좀 있나요?

항상 잘못된 날짜를 뒤로 푸시합니다.

부품. 내 말은 -- 우리는 순간 시간대 문제를 노출하는 예가 있습니까, 아니면 하루의 시작/끝에 DST를 감지하고 적절하게 처리하기 위해 순간에 스마트 코드가 필요합니다. 두 번째는 중간에서 쉬움입니다. moment-tz와 moment 사이를 지나는 영역을 다시 리팩토링해야 한다면 지옥입니다. 차라리 3.0을 기다리고 새 인터페이스에 이 문제가 없기를 바랍니다.

@ichernev 코드가 오늘날의 방식대로라면 이 한 가지 문제에 두 가지 문제가 있습니다. 하나는 @mj1856이 원래 제기한 문제입니다. 자정에 시작하지 않는 날은 펑키한 하루 값으로 끝납니다. 이것은 순간의 문제입니다.

다른 하나는 유효하지 않은 날짜가 표시될 때 해당 유효하지 않은 날짜가 생성자에서 사용되면 그 순간 시간대가 앞으로 이동하지만 해당 날짜에 '추가'되면 뒤로 이동한다는 것입니다. 이것은 현재 시점이 아닌 순간 시간대의 문제입니다. 시간대 인터페이스가 어떻게 변경되는지 잘 모르겠습니다. 조금 생각해봐야 할 것 같습니다.

@maggiepint 명쾌한 설명 감사합니다.

따라서 순간 문제를 해결하려면 endOf('day') 가 정확하지 않습니다. 하루가 끝날 때까지 "조준"하면 됩니다. 00:00이면 완료하고, 그렇지 않으면 두 번째 조준이 00에 도달하면 다시 조준합니다. 00 그렇지 않으면 첫 번째 샷을 사용합니다. 두 번째 목표는 DST를 건너뛰고 한 시간 정도 "왜곡"되면 도움이 됩니다. DST 때문에 하루의 끝이 잘못된 시간인 경우 두 번째 목표는 손상되지 않습니다.

우리는 이 알고리즘을 모든 endOf , 아마도 startOf 에 사용해야 하지만, 현재 우리가 하는 0으로 설정하면 추론하기가 더 어렵습니다.

안녕하세요 여러분, 저도 현재 버전의 moment(2.14.1)에서 이 문제의 영향을 받고 있습니다.

이 문제를 해결하기 위해 #3716을 제출했지만 현재 트랜스파일 이유로 Travis CI에 문제가 있습니다. 더 빨리 조사할 예정입니다.

이것도 관련이 있습니다(기본 브라질 로케일).

같은 날짜의 작업 결과:

순간("2017-10-16T00:59:59.999").subtract(1,'일').endOf('일')
=> "2017-10-16T00:59:59.999"

이봐 - 나는 startOf와 endOf에 대해 이것을 수정하는 #4164를 방금 제출했습니다. 우리가 마침내 이것을 앞으로 나아갈 수 있도록 피드백을 받고 싶습니다.

@mj1856 , DST edge의 endOf 문제가 해결된 것 같아서 PR을 닫았습니다. 이것도 고칠 수 있을까요?

#4164를 테스트했는데 수정된 것 같습니다. 병합을 기다리고 있습니다.