Re: to_timestamp alternatives
От | Adrian Klaver |
---|---|
Тема | Re: to_timestamp alternatives |
Дата | |
Msg-id | 5685C547.2000503@aklaver.com обсуждение исходный текст |
Ответ на | Re: to_timestamp alternatives (gkhan <drjohnpayne@gmail.com>) |
Список | pgsql-general |
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.klaver@aklaver.com
В списке pgsql-general по дате отправления: