Discourse 캘린더가 오늘 중요한 업데이트를 받았습니다 
. 이번 업데이트의 핵심은 fullcalendar 4에서 fullcalendar 6로 마이그레이션하는 것이며, 이를 통해 업데이트된 UI를 제공하게 됩니다:
이 기회를 빌려 다음과 같은 변경 사항도 적용했습니다:
다가오는 이벤트 페이지의 URL을 정리했습니다. 예: /upcoming-events/day/2025/8/2
이벤트 위에 클릭하면 이벤트 미리보기가 표시됩니다
성능이 크게 향상되어 이제 대량의 이벤트를 처리할 수 있게 되었습니다.
이제 fullcalendar에서 제공하는 CSS 변수를 사용하므로, 테마와 호환되지 않는 문제 없이 캘린더가 바로 작동할 수 있습니다.
브라보, 정말 잘했어요! 정말 감사합니다 
작은 질문 하나만 드릴게요. 모바일 부분은 기본값으로 (연도) 목록으로 설정할 수 있을까요?
아니면 또 한 번 말씀드리지만, 정말 좋습니다!!
수고하셨습니다! 해당 URL에서 미국/유럽 날짜 형식 시스템이 모두 지원되나요? 그리고 같은 날에 여러 이벤트가 있는 경우 어떻게 처리되나요?
죄송합니다. 현재는 하나의 URL 형식만 지원됩니다.
이로 인해 해당 날짜/월/연도의 모든 이벤트를 확인하는 데는 문제가 없습니다. 특정 이벤트에 직접 링크를 걸려면 해당 이벤트 게시물로 링크를 걸어 주세요.
실제로 이벤트에 대한 직접 링크를 공유할 수 있지만, 여러 URL 형식을 제공하는 것은 쉬운 일이 아닙니다. 새 기능이 포함된 fullcalendar 6 업데이트를 제공해 주셔서 감사드립니다!
업그레이드 이후, 일부 이벤트에서 주제 게시 시간(정확함)과 캘린더 표시 시간(1시간 빠름) 사이에 1시간 차이가 나는 사례를 확인하고 있습니다. 모든 이벤트에 해당하지는 않습니다.
이 문제는 우리의 로컬 시간대가 서머타임으로 전환되면 해결되거나, 일광 절약 시간이 시작되면 반대로 다른 이벤트들의 시간이 어긋나는 상황이 발생할 수 있습니다. 하지만 모든 이벤트가 영향을 받는 것은 아닙니다. 알려진 문제인가요? 수정 예정이 있나요?
정말 훌륭합니다! 달력을 한 단계 더 끌어올린 것 같아요.
(기본) 월 보기에서 이벤트 제목 텍스트가 줄바꿈되지 않는 것을 확인했습니다. 의도적인 건가요?
데스크톱에서 월 보기로 전체 제목을 볼 수 있으면 좋겠습니다 (?마우스를 올렸을 때 표시되는 방식 등). 이벤트 제목에는 유용한 정보가 많이 담겨 있기 때문입니다. 물론 그렇게 하면 이벤트가 더 많은 공간을 차지하게 될 수 있습니다.
모바일에서는 시간 외에는 거의 표시되지 않는 것 같습니다. 탭하면 자세한 내용을 볼 수 있으므로 크게 문제가 되지 않을 것 같습니다.
마지막으로, 이벤트 표현의 일반적인 방식인 어젠다 뷰가 있다면 매우 유용할 것 같습니다. 캘린더를 통해 이것이 가능한가요?
Right Sidebar Blocks 을 사용하면 가능하다는 것은 알고 있지만, 그건 다른 맥락에서 사용하는 방법입니다.
네, 오늘 수정하겠습니다. 확실한 재현 방법을 찾느라 고생하고 있어요. 감사합니다.
다음 커밋으로 수정되었어야 합니다: FIX: removes support for include_expired param (#34582) · discourse/discourse@249ae00 · GitHub
작은 제안을 하나 드릴게요: 
오늘 날짜로 이동하는 것 대신, 다음 이벤트 날짜로 바로 이동하는 것이 더 좋지 않을까요?
그냥 아이디어 하나일 뿐이에요! 
오늘 오픈될 것으로 예상됩니다. 특정 날짜로 사용자를 연결하려면 원하시는 링크를 지금 바로 만들 수 있습니다: /upcoming-events/day/2025/9/2
감사합니다!
ISO 날짜 형식을 따르는 것이 가능할까요? 즉, YYYY/MM/DD 형식(월과 일은 두 자리 숫자)으로요?
나는 기본적으로 구글이 여기서 하는 방식을 따르고 있습니다:
아, 남에게 더 많은 일을 만들어줄 수 있는데 왜 규정을 따르겠어. 
/day/2025/09/01이 /day/2025/9/1보다 왜 훨씬 더 좋은지 이해하기 어렵네요.
제로를 추가하는 것은 오히려 나쁘다고 생각합니다. 주소 표시줄에서 더 많은 공간을 차지하기 때문입니다.
이것이 더 좋다는 의미는 아닙니다. 다만 더 표준화되었고, Discourse의 다른 부분에서 날짜가 인코딩되는 방식과 일관성이 있을 뿐입니다.
반면에, 현재 구현 방식은 Discourse URL(끝없는 번호 체계가 필요함)과 일관성이 있습니다.
따라서 이는 철학적 결정입니다. URL과의 내부적 일관성인지, 날짜와의 내부/외부적 일관성인지의 문제입니다. 각각 장단점이 있습니다. 저는 현재 구현 방식을 선호합니다.
만약 제가 그 날짜를 쓰기 시작한다면 형식은 mm/dd가 될 것입니다. 거의 모든 곳에서 표준이니까요 — 미국에서 연결되는 경우를 제외하면, 그들은 앞자리 0을 생략하고 단어의 첫 글자를 대문자로 씁니다 
. 또는 공백을 세는 프로그래머들처럼요, 왜냐하면 미국인도 mm/dd를 읽고 사용할 수 있거든요.
결국 이것은 근육 기억의 문제이며, 세계 대부분이 ISO 형식을 사용한다는 사실입니다. 어떤 소프트웨어와 플랫폼이 어떤 형식을 사용하는지 기억하기가 어렵습니다. 그것은 항상 누군가가 지게 되는 질문 중 하나이며, 문제는 어떤 그룹이 가장 큰지입니다.
하! 바이시크드(사소한 논쟁)를 벌이려던 건 아니었어. 순수한 숫자는 숫자 순서로 정렬되고, 앞자리 0은 월과 일이 올바른 순서로 보이도록 해.
여름 시간으로의 현지 시간 변경 전후로 반복 이벤트에서 여전히 이상한 동작이 관찰되고 있습니다. 호스팅 플랜을 사용 중인데, 수정 사항이 배포되기까지 기다리면 되는 건가요?
