Генерация JSON

[Avol-V]

Предлагаю уже сделать генерацию JSON — послужит отправной точкой для #16, да и может ещё пригодиться кому-нибудь возможность загрузить данные в удобном для обработки формате.

Формат мне видится такой (пишу в виде интерфейсов TypeScript, т. к. они гораздо более лаконичные, чем JSON Schema):

/**
 * Календарь
 */
interface Calendar
{
	/** Название календаря */
	title: string;
	/** Ссылка на сам календарь */
	url: string;
	/** Timestamp последнего изменения */
	modified: number;
	/** Массив событий */
	events: CalendarEvent[];
}

/**
 * Событие календаря
 */
interface CalendarEvent
{
	/** Идентификатор */
	uid: string;
	/** Название события */
	title: string;
	/** Ссылка на подробности */
	url: string;
	/** Город, страна проведения */
	city: string;
	/** Timestamp начала */
	timeStart: number;
	/** Timestamp окончания */
	timeEnd: number;
	/** На весь день? */
	allDay: boolean;
}

Например:

{
	"title": "Календарь событий по фронтенду",
	"url": "https://web-standards.ru/calendar.ics",
	"modified": 1503242160160,
	"events": [
		{
			"uid": "2016-11-24-moscowjs@https://web-standards.ru/",
			"title": "MoscowJS 34",
			"url": "https://moscowjs.timepad.ru/event/407854/",
			"city": "Москва, Россия",
			"timeStart": 1479945600000,
			"timeEnd": 1480032000000,
			"allDay": true
		},
		{
			"uid": "2017-08-17-kyivjs@https://web-standards.ru/",
			"title": "KyivJS",
			"url": "http://kyivjs.org/",
			"city": "Киев, Украина",
			"timeStart": 1502983800000,
			"timeEnd": 1502994600000,
			"allDay": false
		}
	]
}

Что можно обсудить:

• title или name? Я использовать первое, т. к. здесь идёт описательный контекст, но в yml используется name, а в ics вообще summary,
• Даты в виде UNIX timestamp — мне кажется это наименее проблемный для конвертации в правильную дату вариант. Проблемой может быть, что он не читаем человеком, но вроде JSON создаётся не для людей, а для программного чтения.
• Для событий на целый день / несколько дней — писать финальную дату на 0 часов следующего дня (в примере так), или на 23:59:59.999 текущего?
• Поле для города — city (как в yml), или location (как в ics). Я использовал city, т. к. это ближе к сути.
• Какие-то поля лишние?
• Чего-то не хватает? Например, можно добавить название часового пояса, но я не придумал, зачем оно может быть нужно, ведь timestamp хранится в UTC.
• Что-то ещё?

Как определимся с видом, я готов это дело добавить.

[fogrew]

1. summary - имхо, всё везде должно называться одинаково. одинаково = предсказуемо. и лучше - по формату извне.
2. timestamp - единственно верный путь. Остальные добавляют кучу боли.
3. Я за 23:59:59.999. Хотя есть ещё предложения на этот счёт в #28
4. location, потому что туда можно писать не только город. Плюс - формат ics предсказуем.
5. Не очень понимаю, зачем нужен в JSON allDay. При текущей схеме либо многодневное мероприятие, тогда автоматом allDay, либо указано время, нет?
6. Было бы круто тащить twitter:image, ну, я указал тут, что имею ввиду.

[Avol-V]

Ну ICS универсален, и описывает поля представления для календаря, мы же в JSON описывает поля данных — поэтому мне не кажется обязательным соответствие summary и location, здесь ближе использование полей из YML, т. к. именно в него данные и пишутся.

Например, изменение содержимого location в ICS может быть вызвано добавлением дополнительных полей в YML (вроде места проведения, помимо города). Эти данные полезно, при этом, сохранить отдельными в JSON, чтобы их можно было использовать в нужном контексте независимо и отображать так, как это требуется в конкретном приложении.

По поводу allDay — на целый день может быть и однодневное, а дата ведь здесь в любом случае хранится в виде timestamp — можно, конечно, определять, что оно начинается в 0:00:00, а заканчивается в 23:59:59, но это ненадёжно и сложно, лучше иметь чёткий флаг.

[fogrew]

Ну, ок, про соответствие убедил. Не нужно.
И про allDay ты прав, это дофига сложно. Лучше оставить.

Получается, имеет смысл делать city и address? Или какие там могут быть дополнительные поля в yml, влияющие на точку на карте?

[Avol-V]

По крайней мере сейчас стоит использовать поле city, с соответствующей информацией из YML, а как появится дополнительное поле с адресом — то и его добавить, отдельным значением.

Но пока такого поля нет — я так понимаю, что Вадим не хочет чрезмерно перегружать и усложнять создание YML файла. Это как с формами — чем больше там полей, там меньше хочется их заполнять.

[pepelsbey]

В рамках new мы без проблем научились читать iCal как источник данных, так что закрываю пока, если не будет новых юзкейсов.