Re: to_timestamp alternatives

From: Alban Hertroys <haramrae(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: gkhan <drjohnpayne(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: to_timestamp alternatives
Date: 2016-01-01 13:15:21
Message-ID: 034CD44D-1ED9-45B0-8598-834ED8076E18@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


> On 01 Jan 2016, at 0:46, Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> wrote:
>
> BTW, my recommendation would be to store in a timestamptz field *with the correct timezone*, and then convert on output as necessary. This is easy to do by either
>
> SET timezone
>
> or
>
> SELECT timestamptz_field AT TIME ZONE '…';

This. When converting the original timestamps to UTC, you lose data. In my experience, you will end up needing that data sooner or later.
Remember, the database stores timestamps in UTC internally anyway, you don't need to the conversion yourself.

> Since you're dealing with GPS data and presumably have lat/long, it shouldn't be hard to do this dynamically either, either by just blindly dividing longitude by 15 or using actual timezone shape polygons and @> or <@.

That would be a bad idea for global data, since not all time zones are full hours apart, or have the same (if any) DST change-over dates. For example, India is currently at UTC+05:30, probably because they wrapped the entire country in the same TZ after their independence.

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Melvin Davidson 2016-01-01 14:51:31 Re: Happy New Year
Previous Message Vladimir Borodin 2016-01-01 10:55:40 Re: how to decrease the promotion time when performing a multiple failovers.....