<blockquote>
<blockquote>
<p>The 'with timezone' variant is the idiomatic way to fix timezone issues. It was created for this purpose and is supported all the way down to the wirelevel protocol. You can fix timezone issues another way, but that's IMHO just a hack.</p>
</blockquote>

<p>My experience is exactly the opposite: timestamps are time_t and always UTC. "With timezone" is a hack which adds unnecessary complexity, and clients supporting implicit timezone conversion are the reason that these bugs exist in the first place.<br>
I'm not trying to outsmart anyone - I'm just trying to avoid unnecessary complication and leakage of presentation-layer concepts into the database. But sadly these appear to be mandated by the SQL standard . We have already fixed the server, but unfortunately the database client libraries are apparently still broken by design.</p>
</blockquote>

<p>Consider these facts :</p>

<ul>
<li>regardless of variant, the timstamps are stored as an 8 bytes integer (always representing utc in the "with timezone" case)</li>
<li>they are sent as text ("YYYY/MM/DD....") to the client, with an explicit unambiguous "+HH:MM" timezone marker if known by the server</li>
<li>the server sometimes needs to work in a specific timezone long before any data is sent to the client (SELECT count(*), to_char(d_tz, 'YYYYMM') FROM foo GROUP BY 2)</li>
<li>ultimately <em>somebody</em> will need to convert to a local timezone for display</li>
</ul><p>The complexity is already there wether you want it or not, it's not an overengineering by PG or SQL. It's not unecessary. It's not just a presentation-layer concept. Once again, you can either fix the issue once server-side, or many times client-side (have fun implementing group-by clientside, btw).</p>

<p>Thanks to SQL and 'with timezone', the common case is that the client should be oblivious of the timezone. That's a good thing: it means less code and less bugs. To reuse your own argument, the problem is with client that try to do their own timezone conversion in the first place.</p>

<p>Don't fall into the trap of treating PG as a "dumb datastore" or you'll just waste time reinventing the wheel.</p>

<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-21486794'>view it on GitHub</a>.<img src='https://github.com/notifications/beacon/uTRSc6ihLa7Shf84BpiOpu5p-sEO603Adi0xI76mcGfT_gJWm4GdBKeaxLg8tieb.gif' height='1' width='1'></p>