날짜 선택기를 사용할 때 시간이 잘못됨: 버그인가요?

안녕하세요,

제 Discourse(2.6.0.beta4)는 Europe/Paris를 Discourse 로컬 날짜 기본 시간대로 설정되어 있습니다. 하지만 시간을 선택하려고 하면 아래 스크린샷에 표시된 것처럼 표시되는 시간이 올바르지 않습니다.

"20:00:00"이라고 입력해도 표시되는 시간은 "오늘, 22:00"입니다. 브라우저에서 실행한 moment.tz.guess()는 "Europe/Paris"를 반환하므로, 제가 정확히 무엇을 잘못하고 있는지 모르겠습니다.

혹시 아이디어가 있으신가요?

감사합니다,

3개의 좋아요

@j.jaffeux 이 문제를 일으키는 원인에 대해 혹시 추측되는 점이 있으신가요?

2개의 좋아요

프랑스어 따옴표 처리가 잘못되었다고 생각합니다. (제 기억이 맞다면 bbcode 문제입니다) 이 문제는 독일어 로케일에 대해서는 이미 해결되었습니다.

https://meta.discourse.org/t/locale-date-timezone-cooking-error-with-french-localization/161532

3개의 좋아요

tz에서 따옴표를 제거합니다. 장기적인 해결책은 아니지만… 그래도 작동하긴 하죠😁

2개의 좋아요

네, 죄송합니다. 월요일/화요일에 자리를 비웠습니다. 로컬에서는 재현이 안 되지만, 같은 문제라고 생각합니다.

다음과 같은 수정을 적용했습니다:

기술적으로 이는 로컬 날짜 관련 버그라기보다 텍스트/마크다운 표시 관련 버그에 가깝습니다. 이 문제에 대해 보다 포괄적인 해결책을 마련하는 것이 좋을 수도 있습니다. 다만, 로컬 날짜 관련 맥락에서만 이 문제에 대한 불만을 접수받은 적이 있는데, 이는 해당 기능이 더 많이 사용되고 수동으로 편집될 가능성이 더 높기 때문일 것으로 추측됩니다.

4개의 좋아요

작동하지 않는 것 같습니다. discourse-local-dates.js.es6 파일의 99번째 줄 조건문과 관련된 문제일 수도 있습니다.

if (config.timezone && moment.tz.names().includes(config.timezone))

이 조건은 현재 참이 아니지만(참이어야 합니다).

수정
다른 브랜치에 수정 사항이 커밋된 것을 방금 알게 되었습니다. 다시 돌아올게요 :sweat_smile:
… 그래서 확인해 보니,

[date=2020-12-20 time=15:00:00 timezone=„Europe/Paris“]
[date=2020-12-20 time=15:00:00 timezone=Europe/Paris]
[date=2020-12-20 time=15:00:00 timezone="Europe/Paris"]
[date=2020-12-20 time=15:00:00 timezone=«Europe/Paris»]

순서대로 각각 맞다, 맞다, 틀리다, 틀리다입니다.

1개의 좋아요

그리고 제 프랑스어 AZERTY 키보드에서는 따옴표가 실제로는 "이에요. 복사/붙여넣기 없이 «나 »를 만드는 방법을 모르겠는데, 아마도 정상적인 것 같습니다 :thinking:

저는 분명히 “잘못된” 것을 재현하지 않습니다:

문제는 바로 이겁니다. 이 따옴표는 여러분이 직접 작성하는 것이 아니라, 어떤 변환 과정이 일어나는 것이기 때문이죠.

1개의 좋아요

마지막 두 항목은 16시간이 걸리는데, 좀 이상하네요.

문제를 재현할 수 있다고 하셨으니, 다음 위치에 로그를 추가해 보시겠어요? https://github.com/discourse/discourse/blob/master/plugins/discourse-local-dates/assets/javascripts/lib/discourse-markdown/discourse-local-dates.js.es6#L15

console.log(matches[1]);

그리고 정확히 어떤 결과가 나오는지 보여주세요.

1개의 좋아요

물론이지! 하지만 거기에선 좀 헷갈렸어 :smile: 레일즈 로그를 원하시는 건가요? 저는 전문가가 아니라 그냥 약간 열정적인 사람일 뿐이에요!
그리고 죄송합니다, 5를 6으로 잘못 읽었거나… 모르겠어요, 세 번째 것만 작동하지 않아요. 제 실수예요. 네 번째 것은 미리보기에서는 작동하지 않지만, 최종 게시글에서는 정확해요 :crazy_face:

1개의 좋아요

다른 pull request를 하나 더 올렸으니, 자세히 살펴보기 전에 이걸 먼저 기다려 주세요.

2개의 좋아요

내가 파악할 수 있는 것은 속성 "data-timezone"이 누락되어 있다는 것입니다(기능이 작동하지 않을 때)

Message

  Post Update (1.1ms)  UPDATE "posts" SET "raw" = '[date=2020-12-20 time=12:00:00 timezone=Europe/Paris]
[date=2020-12-20 time=12:00:00 timezone="Europe/Paris"]', "self_edits" = 3, "cooked" = '<p><span data-date="2020-12-20" data-time="12:00:00" class="discourse-local-date" data-timezone="Europe/Paris" data-email-preview="2020-12-20T11:00:00Z UTC">2020-12-20T11:00:00Z</span><br>
<span data-date="2020-12-20" data-time="12:00:00" class="discourse-local-date" data-email-preview="2020-12-20T12:00:00Z UTC">2020-12-20T12:00:00Z</span></p>', "baked_at" = '2020-10-21 15:25:53.050518', "updated_at" = '2020-10-21 15:25:53.050721' WHERE "posts"."id" = 1954
1개의 좋아요

네, 변환된 따옴표를 이해하지 못하기 때문이에요. 그래서 알려진 상태로 강제하려고 하는 거예요.

2개의 좋아요

물어보는 것조차 미안하지만, 그 이후로는 방치할게요. \&laquo;의 ;가 && moment.tz.names().includes(config.timezone) 실패의 원인인 줄 알았거든요.
config.timezone이 HTML 이스케이프 처리되어 있는 건가요?

1개의 좋아요

걱정 마세요, 제 말이 틀렸을 수도 있죠 :smiley:

질문하신 내용은 기본적으로 제가 하는 것과 같지만, 예상하시는 시점에 수행되지 않는다는 점이죠. 아마 그 방식도 작동할 수 있을 겁니다. 예를 들어, 제 수정 사항 이전에는 다음과 같은 코드가:

[date=2020-12-20 time=15:00:00 timezone=«Europe/Paris»]

파싱된 마크다운에서 이러한 속성을 반환했습니다:

{"date"=>"2020-12-20", "time"=>"15:00:00", "timezone"=>"«Europe/Paris»"}

이렇게 되면 문제가 명확해집니다.

제 수정 사항 이후에는 다음과 같은 결과를 얻습니다:

{"date"=>"2020-12-20", "time"=>"15:00:00", "timezone"=>"Europe/Paris"}

저는 이전에 따옴표 처리에 대한 모든 경우의 수를 다루지 못했다고 생각합니다. 제가 만든 두 번째 커밋을 시도해 보셨나요?

2개의 좋아요

네…

하지만 원본(raw)이

[date=2020-12-20 time=15:00:00 timezone=«Europe/Paris»]

이 아니라 이미

[date=2020-12-20 time=15:00:00 timezone="Europe/Paris"]

인 것 같습니다.

아마 "더 아래 단계"에서 무언가 일어나고 있는 것 같습니다 :thinking: , 정확히 어디서 일어나는지는 모르겠습니다. \&laquo;와 \&raquo;가 어디서 도입되는지 모르겠네요.
아 맞다! 컴포저 미리보기에서 볼 수 있습니다.
[date=2020-12-15 time=14:00:00 timezone="Europe/Paris"
을 입력하면
[date=2020-12-15 time=14:00:00 timezone=« Europe/Paris »
로 변환됩니다.

1개의 좋아요

네, 아마도 프론트엔드와 백엔드에 두 가지 문제가 있는 것 같습니다. 이전 수정으로 독일어 대소문자 처리가 확실히 개선되었기 때문에, 프론트엔드에도 동일한 정규 표현식을 적용하면 될 것 같습니다. 이 문제를 재현할 수 있으면 좋겠네요 :sweat_smile:

내일 진행하겠습니다.

5개의 좋아요

@Benjamin_D / @j.jaffeux 아직 문제가 남아 있나요?

1개의 좋아요

그렇다고 생각해요, 하지만 저는 좀 뒤처져 있어요. 아직 2.6.0 beta5를 쓰고 있거든요 :flushed: 10월 이후로 해당 이슈에 대한 커밋은 보지 못했어요.