Change state.lastchange from unix timestamp to rfc3339 (JSON schema date-time)

[the-metalgamer]

I would like to change state.lastchange type from number to date-time.

The problem lies within that a simple number does not carry timezone information with it. As there is no timezone field specified in the API, apps cannot determine in which timezone a space lives.

JSON Schema defines the date-time type, which is the rfc3339 format.

I think also that in future all time related properties should be date-time type, if there are added

[dbrgn]

I'm a bit unsure about this. The timezone of the space can already be derived from the location. And unix timestamps are easy to handle and easy to parse.

Also, the time of 23:00 CET and 22:00 UTC are equivalent. A datetime string does not necessarily use the timezone of the space itself. I could imagine many spaces specifying dates in UTC.

[dns2utf8]

The unix timestamp is defined with a timezone, quote Wikipedia:

... the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970

The last definition of the standard did not have a time type: ECMA-404 Can you share a link to a more recent document or a discussion to it? I am personally interested in it, because the "standard" JSON lacks such a type.

[the-metalgamer]

The problem is not that UNIX times is defined as UTC, but that the spaceapi doesn't provide a timezone property.

For example, the MyHackerspace shows the lastchange as UTC which is a little inconvenient.

Sorry, I thought date-time is a type in JSON schema. It is actually a format attribute. http://json-schema.org/latest/json-schema-validation.html#rfc.section.7.3.1

[dbrgn]

The problem is not that UNIX times is defined as UTC, but that the spaceapi doesn't provide a timezone property.

For example, the MyHackerspace shows the lastchange as UTC which is a little inconvenient.

Well, but that's the perfect example where you want to know at which point in time the event (lastchange) happened, and not what the local time was when it happened.

[the-metalgamer]

Well, but that's the perfect example where you want to know at which point in time the event (lastchange) happened, and not what the local time was when it happened.

Right. But I think, that apps should be able to display the time in the timezone where the space is located. (Maybe also configurable)

So a timezone property would still be good to have in the API.

[dns2utf8]

Do you propose a new property with the timezone, the space is located in?

[dbrgn]

I also think that a separate timezone field would be more useful than adding timezones to datetime fields. The semantics are different. A timezone field would be clearly defined as "the timezone of the space", while a datetime field is usually defined as "a point in time".

[rorist]

+1 A separate field is good, so we can be as forward compatible as possible.

[the-metalgamer]

Yes, then that's maybe the best way to do it.

Now where should it be specified?

[dbrgn]

That's a good question. Probably either under contact, or under location. I think I'd favor location. (Btw, the timezone is slightly redundant when already having the location, but I think that's fine.)

There's another issue though. For a space in central Europe, what time zone would you specify, CET or CEST? Simply specifying the UTC offset won't work either, because then you also have +1 during winter and +2 during summer.

We can't have a field for summer and winter time either, or a flag for DST, because the DST switching day is not the same everywhere in the world.

https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations

[rnestler]

Maybe use the values from the Tz database?

[dbrgn]

Maybe use the values from the Tz database?

Ah, obviously. Stupid me :)

[the-metalgamer]

I would also favor location. I would also use the values from the Tz database.