> On 08/29/2014 04:59 AM, Kevin Grittner wrote:
>> I just took a quick look at the spec to refresh my memory, and it
>> seems to require that the WITH TIME ZONE types store UTC (I suppose
>> for fast comparisons), it requires the time zone in the form of a
>> hour:minute offset to be stored with it
Hi Craig,
On Fri, Aug 29, 2014 at 10:17:17AM +0800, Craig Ringer wrote:
> (...) It should also discuss the approach of storing a (instant
> timestamptz, timezone text) or (instant timestampts, tzoffset
> smallint) tuple for when unambiguous representation is required.
>
> (I guess I just voluntee
Kevin Grittner writes:
> It was actually rather disappointing to hear that we had a
> conforming implementation and changed away from it circa the 7.2
> release;
That is not the case. The existing implementation is work that Tom
Lockhart did around 6.3 or so. It was called timestamp at the time
Tom Lane wrote:
> Kevin Grittner writes:
>
>> But the standard doesn't say anything about storing a time zone
>> *name* or *abbreviation* -- it requires that it be stored as UTC
>> with the *offset* (in hours and minutes). That makes it pretty
>> close to what we have -- it's all about a differe
On 08/29/2014 05:28 AM, Tom Lane wrote:
"k...@rice.edu" writes:
On Thu, Aug 28, 2014 at 03:33:56PM -0400, Bruce Momjian wrote:
So the standard requires storing of original timezone in the data type?
I was not aware of that.
I do not have a copy of the SQL 92 spec, but several references to t
On 08/29/2014 04:59 AM, Kevin Grittner wrote:
> I just took a quick look at the spec to refresh my memory, and it
> seems to require that the WITH TIME ZONE types store UTC (I suppose
> for fast comparisons), it requires the time zone in the form of a
> hour:minute offset to be stored with it, so y
On Thu, Aug 28, 2014 at 03:25:49PM -0700, Josh Berkus wrote:
> On 08/28/2014 02:25 PM, Kevin Grittner wrote:
> > But the standard doesn't say anything about storing a time zone
> > *name* or *abbreviation* -- it requires that it be stored as UTC
> > with the *offset* (in hours and minutes). That m
Kevin Grittner writes:
> But the standard doesn't say anything about storing a time zone
> *name* or *abbreviation* -- it requires that it be stored as UTC
> with the *offset* (in hours and minutes). That makes it pretty
> close to what we have -- it's all about a difference in
> presentation. A
On 08/28/2014 02:25 PM, Kevin Grittner wrote:
> But the standard doesn't say anything about storing a time zone
> *name* or *abbreviation* -- it requires that it be stored as UTC
> with the *offset* (in hours and minutes). That makes it pretty
> close to what we have -- it's all about a difference
Alvaro Herrera wrote:
> Kevin Grittner wrote:
>
>> But the standard doesn't say anything about storing a time zone
>> *name* or *abbreviation* -- it requires that it be stored as UTC
>> with the *offset* (in hours and minutes). That makes it pretty
>> close to what we have -- it's all about a dif
Kevin Grittner wrote:
> But the standard doesn't say anything about storing a time zone
> *name* or *abbreviation* -- it requires that it be stored as UTC
> with the *offset* (in hours and minutes). That makes it pretty
> close to what we have -- it's all about a difference in
> presentation. An
Alvaro Herrera wrote:
> Kevin Grittner wrote:
>
>> I just took a quick look at the spec to refresh my memory, and it
>> seems to require that the WITH TIME ZONE types store UTC (I suppose
>> for fast comparisons), it requires the time zone in the form of a
>> hour:minute offset to be stored with i
Kevin Grittner wrote:
> I just took a quick look at the spec to refresh my memory, and it
> seems to require that the WITH TIME ZONE types store UTC (I suppose
> for fast comparisons), it requires the time zone in the form of a
> hour:minute offset to be stored with it, so you can determine the
>
"k...@rice.edu" wrote:
> On Thu, Aug 28, 2014 at 03:33:56PM -0400, Bruce Momjian wrote:
>> So the standard requires storing of original timezone in the
>> data type? I was not aware of that.
>
> I do not have a copy of the SQL 92 spec, but several references
> to the spec mention that it define
"k...@rice.edu" writes:
> On Thu, Aug 28, 2014 at 03:33:56PM -0400, Bruce Momjian wrote:
>> So the standard requires storing of original timezone in the data type?
>> I was not aware of that.
> I do not have a copy of the SQL 92 spec, but several references to the
> spec mention that it defined
On Thu, Aug 28, 2014 at 03:33:56PM -0400, Bruce Momjian wrote:
> On Thu, Aug 28, 2014 at 11:26:53AM -0700, Kevin Grittner wrote:
> > Steve Crawford wrote:
> >
> > > I have always considered "timestamp with time zone" to be a bad
> > > description of that data type but it appears to be a carryover
On Thu, Aug 28, 2014 at 11:26:53AM -0700, Kevin Grittner wrote:
> Steve Crawford wrote:
>
> > I have always considered "timestamp with time zone" to be a bad
> > description of that data type but it appears to be a carryover
> > from the specs. It is really a "point in time"
>
> I agree. While
2014-08-28 20:26 GMT+02:00 Kevin Grittner :
> Steve Crawford wrote:
>
> > I have always considered "timestamp with time zone" to be a bad
> > description of that data type but it appears to be a carryover
> > from the specs. It is really a "point in time"
>
> I agree. While what timestamptz impl
Steve Crawford wrote:
> I have always considered "timestamp with time zone" to be a bad
> description of that data type but it appears to be a carryover
> from the specs. It is really a "point in time"
I agree. While what timestamptz implements is a very useful data
type, I think it was a very
On 08/28/2014 01:51 AM, rohtodeveloper wrote:
Hi,all
I have a question about data type "timestamp with time zone".
Why data of timestamptz does not store value of timezone passed to it?
Considering the following example.
postgres=# select '2014-08-28 14:30:30.423602+02'::timestamp with time
z
Hi,all
I have a question about data type "timestamp with time zone".
Why data of timestamptz does not store value of timezone passed to it?
Considering the following example.
postgres=# select '2014-08-28 14:30:30.423602+02'::timestamp with time zone;
timestamptz
-
21 matches
Mail list logo
