On 12/31/2015 03:05 PM, gkhan wrote:
Follow-up:
My initial question was about oddly-formatted date/times. The suggested
solution of casting directly to timestamp with ::timestamp is not as
flexible as the to_timestamp function that I was trying to avoid. For
example, this fails because of the day-before-month format:
SELECT ('18.09.2015 18:01:40')::timestamp
--ERROR: date/time field value out of range
It it where me I would deal with this in the original data, either
pre-import or as part of the import process. Presumably for a given data
set the date/time format is the same and therefore more easily
converted. The goal would be to then have a 'standard' date/time output
format landing in the database. Seems easier then going back after the
fact and building a process for all eventualities.
whereas this works, but results in a timestamp *with* time zone that makes
assumptions about daylight savings times:
SELECT to_timestamp('18.09.2015 18:01:40','DD.MM.YYYY HH24:MI:SS')
I ended up with this simple solution, which does what I wanted to and avoids
time zones:
SELECT (to_date('18.09.2015','DD.MM.YYYY') ||' '||'18:01:40')::timestamp
Adrian: thanks for your observation about wildlife-human interactions --
that is a useful reminder since I'll be looking at traffic patterns.
Just part of a bigger observation that it is often assumed humans are
not animals.
--
Adrian Klaver
adrian.kla...@aklaver.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
