Re: Using Epoch to save timestamps in 4 bytes?

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>, "Francisco Reyes" <lists(at)stringsutils(dot)com>, "PostgreSQL general" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Using Epoch to save timestamps in 4 bytes?
Date: 2008-05-09 12:51:26
Message-ID: b42b73150805090551g636fd5a6r5b4ab48fa1ac7bda@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, May 9, 2008 at 3:15 AM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> On Thu, May 8, 2008 at 10:00 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>
>> Our timestamp has a much larger range than a 4-byte time_t, docs say:
>>
>> <entry>4713 BC</entry>
>> <entry>294276 AD</entry>
>
> Which is normally great. Doesn't it have greater precision in the
> modern era or something like that?
>
> If you compile for integer dates do they have the same range?

no. that's actually the integer range. the float range is 4713 BC to
5874897 AD. Of course, at the outer ranges of the scale, the
precision is going to be really lousy.

Anyways, to the OP, a 4 byte time_t is to small a type to be the
timestamp. There are just too many things that need greater
range/precision to make it the default. Also, postgresql does not
store epoch, but it's own custom type with its own bias, etc. There
is nothing wrong with storing int4 epoch in your tables to save a
little space if that suits your application.

merlin

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Fernando Schapachnik 2008-05-09 12:55:02 Re: Is this a bug? (changing sequences in default value)
Previous Message Merlin Moncure 2008-05-09 12:45:19 Re: Is this a bug? (changing sequences in default value)