Re: date with month and year

From: "Karsten Hilbert" <Karsten(dot)Hilbert(at)gmx(dot)net>
To:
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: date with month and year
Date: 2015-05-21 21:27:34
Message-ID: trinity-bc419777-a971-4cfe-9c01-06ccf5db25f1-1432243654407@3capp-gmx-bs45
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> Anyway, I agree that you have to store the time zone *somewhere*, and I
> suppose that's the reason Joshua remarked that you really shouldn't use
> WITHOUT TIME ZONE. And often a time has one perspective that is
> "canonical" or "preferred", e.g. the time zone of the user who created
> the object. And in that case WITH TIME ZONE gives you a convenient place
> to store that.

No it doesn't.

WITH TIME ZONE simply means that whatever the user sends to
the database is meant to represent that time zone.

As far as PostgreSQL is concerned it will convert that
to UTC, store UTC

AND THROW AWAY THE TIMEZONE INFORMATION

While that's correct in mathematical terms (the stored instant-in-time
is *known* to be "good" at UTC) it does throw away information, namely
the storing-client-timezone data. If you want to retain that (rather
than convert UTC to the retrieving client's timezone) you'll have to
store that yourself in an extra field.

> I think I still prefer a more "relativistic" approach
> where times have no preferred perspective,

That's meaningless. Time has, by its very definition, a perspective. It's
just that for "canonical" times people usually agree on storing the
perspective "UTC". Other than that it would be akin to a byte string
without encoding -- you can't tell what it means.

Karsten

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2015-05-21 21:29:20 Re: Unit tests and foreign key constraints
Previous Message Thomas Kellerer 2015-05-21 21:27:23 Re: date with month and year