Hacker News Reader

Comment by canucker2016 | Hacker News Reader

canucker2016

iCalendar is designed as an interchange format not as a storage format for fast access of calendar data.

The format shows its age - you can tell it was designed before XML/JSON were "hot".

see https://en.wikipedia.org/wiki/ICalendar

Showed up to a doctors appointment during their lunch break once because iCal supports the time format "TZ is whatever is local, trust me" and the device I used to add an appointment was set to UTC, not UTC+1.

My doctors calendar app vendor was pretty happy I found the root cause of their very occasional mystery appointment drift too.

> “TZ is whatever is local, trust me”.

New years is midnight, local time, wherever you are. Trust me.

If I invite you (who lives in Spain, let’s say) to fly over and enjoy my New Year’s party (in New Zealand) it definitely is not going to occur at “midnight local time wherever you are” - Trust me.

(Actually there’s a famous missing person’s case related to a New Year’s party in New Zealand … I don’t think that timezones were part of what went wrong, but I can’t be sure.)

The correct behaviour would be to actually use the timezone field of an ISO date and not to assume that convertion to/from utc is always lossless.

A single number is not enough to store a datetime.

I blame databases for only storing half of the data and leaving the other half to the environment.

It is also a data model that amounts to a de facto standard across all real calendaring apps. The text serialization sure is ugly and who would want to touch it unless they had to, but that's just a parsing problem. The wiki page shows 14 component types, who is ever going to think of that many when designing a replacement schema? Why not just use the data model you already have 'for free'

It's a data model for an early-mid 1990s calendaring app (Lotus Organizer / Microsoft Schedule+).

If that works for you, go for it.

But what is the exact criticism here, e.g the serialized form doesn't look "nice" when you open the file?

A defacto standard for interchange ("feeds" announcing changes to activities), not for a database (remembering a large set of activities indefinitely).

The appropriate schemas are vastly different: a message like iCalendar should be simple and self-contained (leaving cleverness to the applications exchanging it), while a database like the article discusses should be normalized (nontrivial structures and queries aren't a problem).

It’s like the email format - it’s the wild west trying to parse these things, it doesn’t help that date/time is already a tricky subject.

In the Wild West things were easier —

“Meet me at high noon!”

Was never met with -

“High noon? What time zone?”

> you can tell it was designed before XML/JSON were "hot

or you can tell it was designed by people who care more about performance.

> > you can tell it was designed before XML/JSON were "hot

> or you can tell it was designed by people who care more about performance.

I doubt parsing iCal is significantly more performant than JSON for most use cases. In fact I can image it being less so in more cases than it is more so, and as close to the same as makes no odds in the vast majority of cases.

Parsing iCal was far more performant than parsing JSON as your parser could simply start at the first byte, and follow the spec — whereas a JSON parser would first need to wait for ten years before JSON was invented.

The original comment implied that parsing JSON was less efficient (either in terms of coding required, or the resulting CPU use) than parsing iCal.

While it is true that dealing with json by hand is going to be more work than just importing an iCal library, I'm comparing apples to apples and suggesting dealing with json "by hand" is no more faff than dealing with iCal "by hand", and that dealing with either via a good library equally gives no benefit to iCal.

Most data formats used in high performant scenarios, for example in finance, are very basic for a reason. You also get the benefit of being able to start processing the file immediately line by line, instead of having to read and parse the entire file.

the iCalendar rfc shows nov 1998 - https://www.rfc-editor.org/rfc/rfc2445

iCalendar is based on vCalendar, http://www.imc.org/pdi/vcal-10.txt - need to go to archive.org to see it, which shows Sept 1996.

from wikipedia, XML is listed as first published in Feb 1998, JSON is early 2000s.

edit: XML'd iCalendar, 2011 - https://datatracker.ietf.org/doc/html/rfc6321

JSON'd iCalendar, 2014 - https://datatracker.ietf.org/doc/html/rfc7265

Reply on news.ycombinator.com