<blockquote>
<p>Indeed - the timestamps aren't in a definite timezone as far as the database is concerned (except that it assumes some for conversions from "with timezone") - my meaning was that we define all timestamps to be in UTC, and always internally work in UTC as if we're using time_t.</p>
</blockquote>

<p>via #postgresql, while thinking about <a href="https://github.com/pnorman/openstreetmap-api-testsuite/issues/1" class="issue-link" title="Dates">pnorman/openstreetmap-api-testsuite#1</a></p>

<pre><code>22:02 < RhodiumToad> easy then - timestamp with time zone has, in pg, exactly the same semantics as time_t
22:02 < RhodiumToad> (except for more range and resolution)
22:04 < pnorman> the main API software which is the main user of this database schema is actually written in ruby in rails, but I strongly suspect no code changes are needed except to update the schema
22:05 < RhodiumToad> iirc rails these days does have the option to behave sanely with timestamp with time zone
22:05 < RhodiumToad> but I don't use it myself, that's just from helping other people with it
</code></pre>

<hr><blockquote>
<blockquote>
<p>A simple work-around may be to set $TZ when running Osmosis.<br>
That's a good quickfix, but means that the whole of osmosis will run with<br>
the server's timezone, which might be overkill.</p>
</blockquote>
</blockquote>

<p>Yes - I think it would screw up progress displays at the least</p>

<blockquote>
<p>A cleaner option is to use the AT TIME ZONE construct when running an sql query:</p>

<div class="highlight"><pre><span class="k">SELECT</span> <span class="nb">date</span> <span class="k">AT</span> <span class="n">TIME</span> <span class="k">ZONE</span> <span class="s1">'utc'</span> <span class="k">from</span> <span class="n">current_foobar</span><span class="p">;</span>
</pre></div>

<p>This will tell PG that the 'without timezone' value is stored in UTC. The<br>
server can then check the client's timezone setting, and send the value in<br>
the client's expected timezone. It works similarly for inserts. This has<br>
the advantage that a regional osm website can continue to use its local<br>
timezone for user-facing timestamps without getting confused the the server's<br>
timezone.</p>

<p>It's not as clean a solution as altering the db schema (because it requires<br>
the client to modify its sql queries and it requires the client code to know<br>
what timezone the server's timestamps actualy are in), but it avoid the<br>
lenghty "alter table".</p>
</blockquote>

<p>Well, the output OSM XML is all in UTC in the format <code>2012-09-30T17:00:00Z</code></p>

<p>For cgimap how it gets this is it converts to a string in postgresql, see <a href="https://github.com/zerebubuth/openstreetmap-cgimap/blob/8bfff6/src/backend/apidb/writeable_pgsql_selection.cpp#L399">https://github.com/zerebubuth/openstreetmap-cgimap/blob/8bfff6/src/backend/apidb/writeable_pgsql_selection.cpp#L399</a> which does </p>

<div class="highlight"><pre><span class="n">to_char</span><span class="p">(</span><span class="n">n</span><span class="p">.</span><span class="k">timestamp</span><span class="p">,</span><span class="s1">'YYYY-MM-DD"T"HH24:MI:SS"Z"'</span><span class="p">)</span>
</pre></div>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>Reply to this email directly or <a href='https://github.com/openstreetmap/openstreetmap-website/issues/375#issuecomment-21677498'>view it on GitHub</a>.<img src='https://github.com/notifications/beacon/uTRSc6ihLa7Shf84BpiOpu5p-sEO603Adi0xI76mcGfT_gJWm4GdBKeaxLg8tieb.gif' height='1' width='1'></p>