Remove radio_show

[gidsi]

Fixes #34

[koalatux]

I would rather use RFC3339 as a time format. JSON is already human readable and using a human readable time format lets fewer errors go unnoticed.

JSON Schema's date-time format can be used to only allow strings in the valid RFC3339 format.

[gidsi]

I would rather use RFC3339 as a time format. JSON is already human readable and using a human readable time format lets fewer errors go unnoticed.

JSON Schema's date-time format can be used to only allow strings in the valid RFC3339 format.

RFC3339 would get us at least around the durations, but i would be against RFC3339 and ISO8601 altogether due to their complexity (the first blog post you find that try's to validate a RFC3339 date time with a regex already got it wrong).

I don't think as many people consume or write the file manually (beside quick debugging, but i wouldn't optimize for that), and a lot of spaces don't even pretty print their JSON file. So JSON is not really human readable in my opinion (compared to e.g. yaml), im not even sure if i think that RFC3339 is human readable since i just have a rough idea what time 2019-09-30T21:00:00-02:00 is in my local time.

I would try to stay away from the possibility to define timezones inside the date-time field as far as possible. It adds a lot of complexity to any software since timezones itself are quite complicated and errors usually are hard to debug.

So, my opinion would be to stick with Unix timestamp since we don't have the need to have it human readable, we don't have the need to display timestamps before 1970 and it's quite simple since all unsigned int are valid formats.

[dbrgn]

Hm, why is this even about a date? Is the start and end of a radio show not usually time based? Or is the idea that every hackerspace lists the datetime of the next broadcast?

[gidsi]

Hm, why is this even about a date? Is the start and end of a radio show not usually time based? Or is the idea that every hackerspace lists the datetime of the next broadcast?

It's about broadcasts (Description: "A list of radio shows that your hackerspace might broadcast."). How would you use start/end otherwise? In terms of duration?

radio_show is also a field that no one uses right now.

[dbrgn]

I wonder if we should deprecate it instead... I'm not sure whether it makes much sense as it's defined right now. Absolute times are a bit strange for a radio broadcast which is usually periodic.

[gidsi]

I wonder if we should deprecate it instead... I'm not sure whether it makes much sense as it's defined right now. Absolute times are a bit strange for a radio broadcast which is usually periodic.

I would be happy about that too.

[dbrgn]

Idea by @koalatux: It would be better to define a link to a radio show calendar feed instead of specifying all radio shows directly.

@gidsi you have a tool to check what keys are being used, right? Where can we find that? Is anyone publishing any radio shows?

Unless it's being used actively, I'd deprecate radio_show in the next version and remove the field in 0.15.

(Unrelated issue: The feeds object needs to be improved, but that's something that we can discussin a separate issue.)

[gidsi]

All statics about the directory can be found in grafana

[dbrgn]

The key is never used. Let's deprecate it, to be removed in 0.15.

[gidsi]

I've removed the radio_show field, no one is using it anyways right now.

[rnestler]

@gidsi Maybe rename the PR title as well.