Currently the current_nodes, current_ways and current_relations tables include a timestamp column of type TIMESTAMP WITHOUT TIME ZONE.
I've asked around and consulted some sources and the advice I got was best summarized as
19:12 <RhodiumToad> pnorman: unless you're writing a calendaring/scheduling app, timestamp with time zone is pretty much always the way to go
This is not purely a theoretical concern. Currently there is no way to my knowledge to load to an apidb that does not result in time zone errors. See this osmosis discussion
Neither the rails port nor cgimap returns the correct timestamps right now on any instance other than osm.org running on a server where the local time is not set to UTC, because the problem is in the database.
Currently the current_nodes, current_ways and current_relations tables include a timestamp column of type
TIMESTAMP WITHOUT TIME ZONE.I've asked around and consulted some sources and the advice I got was best summarized as
19:12 <RhodiumToad> pnorman: unless you're writing a calendaring/scheduling app, timestamp with time zone is pretty much always the way to goThis is not purely a theoretical concern. Currently there is no way to my knowledge to load to an apidb that does not result in time zone errors. See this osmosis discussion
Neither the rails port nor cgimap returns the correct timestamps right now on any instance other than osm.org running on a server where the local time is not set to UTC, because the problem is in the database.
Cross-reference pnorman/openstreetmap-api-testsuite#1 cc: @brettch, @zerebubuth, @iandees