Спасибо за вашу работу! Поддерживаются ли в этих URL-адресах оба формата дат (США/ЕС)? И что произойдет, если в один день запланировано несколько событий?
Извините, но пока мы поддерживаем только один формат URL.
Это не мешает вам просматривать все события за этот день/месяц/год. Если вы хотите создать прямую ссылку на конкретное событие, используйте ссылку на пост события.
Действительно, прямую ссылку на событие можно поделиться, а предоставление нескольких форматов URL — непростая задача. Мы уже благодарны вам за то, что вы предоставляете нам это обновление для FullCalendar 6 с новыми функциями!
После обновления я наблюдаю случаи расхождения в 1 час между временем публикации темы (верное) и временем, отображаемым в календаре (на час раньше), по некоторым событиям, но не по всем.
Это либо исправляется после перехода нашего часового пояса на летнее время, либо, наоборот, вызывает сбой в отображении других событий после начала перехода на летнее время. Однако не все события затрагиваются. Это известная проблема? Есть ли в разработке исправление?
Было бы здорово видеть полные заголовки в виде «Месяц» на настольных компьютерах (возможно, при наведении), так как они часто содержат полезную информацию. Конечно, это означало бы, что события могли бы стать более «жадными» и занимать больше места.
Календарь для мобильных устройств
Кроме того, на мобильных устройствах редко видно что-то кроме времени. Думаю, это не так важно, так как легко нажать на событие, чтобы увидеть подробности.
Наконец, было бы очень полезно иметь вид «Повестка дня», который является распространенным способом отображения событий. Возможно ли это реализовать через календарь?
Я знаю, что это можно сделать с помощью Right Sidebar Blocks, но это в другом контексте.
Я думаю, что сегодня обычно ожидается открытие. Если вам нужно предоставить пользователям ссылку на конкретный день, вы можете просто создать нужную ссылку прямо сейчас: /upcoming-events/day/2025/9/2
Это не лучше. Просто более стандартизировано и согласуется с тем, как даты кодируются в других частях Discourse.
С другой стороны, текущая реализация согласуется с URL-адресами Discourse (которые требуют нумерации без ограничений).
Таким образом, это философское решение: внутренняя согласованность с URL-адресами или внутренняя/внешняя согласованность с датами. У каждого варианта есть свои плюсы и минусы. Я предпочитаю текущую реализацию.
Если бы я начал писать эту дату, формат был бы мм/дд. Это стандарт практически повсюду — за исключением случаев, когда соединение из США, где они опускают ведущие нули и начинают слова с заглавных букв . Или когда речь идет о программистах, считающих пробелы, ведь даже американцы умеют читать и использовать формат мм/дд.
Так что это вопрос мышечной памяти и факта, что большинство людей привыкли к формату ISO, и трудно запомнить, какое программное обеспечение и платформа используют какой формат. Это один из тех вопросов, где всегда кто-то проигрывает — вопрос лишь в том, какая группа больше.
Ха! Извините, я не хотел вдаваться в детали. Чистые числа сортируются по числовому значению, а ведущие нули обеспечивают правильный порядок отображения месяцев и дней.
Я всё ещё наблюдаю некорректное поведение повторяющихся событий до и после перехода на летнее время. Мы находимся на хостинг-плане, так что это просто вопрос ожидания, пока исправление будет внедрено?