search

popolo-project / popolo-spec

International legislative data specifications
http://www.popoloproject.com/
99 stars 18 forks source link

time zone information #11

Closed jpmckinney closed 11 years ago

jpmckinney commented 11 years ago

How should the timezone be communicated for time-sensitive information? Billy uses a capitol_timezone key in its metadata dictionaries. This becomes an issue once tracking multiple jurisdictions. Should a time zone field be added to Organization?

jamesturk commented 11 years ago

I'd suggest that time zone be embedded in any time sensitive fields or just mandate everything is UTC. capitol_timezone is an unfortunate situation that I wouldn't want to recreate, an organization or even a state might span multiple timezones so there isn't really anywhere safe to store these besides the times themselves

jpmckinney commented 11 years ago

I think all times should be stored as UTC, yes - I can make that more explicit in the spec.

In terms of reading from the DB and converting the time to the appropriate timezone, do we leave it up to the UI to figure out which timezone the user would want times displayed in?

evdb commented 11 years ago

In terms of reading from the DB and converting the time to the appropriate timezone, do we leave it up to the UI to figure out which timezone the user would want times displayed in?

Yes. It'll almost certainly need to do some humanising of the time into a readable string. It also simplifies any situation where multiple results are returned or mixed together if all times are UTC.

jpmckinney commented 11 years ago

OK, I've updated the serialization part of the spec. Is this issue resolved then (the question was whether a new field was needed, and the consensus seems to be that it is not)? I don't think this issue is referred to by the spec or the wiki - I assume you just found it in the queue?

jpmckinney commented 11 years ago

Appears to be resolved.