This thread has been added as a link on the TODO list under TODO.detail.
---
Dennis Bjorklund wrote:
I've made a partial implementation of a datatype timestamp with time
zone as described in the sql standard. The current
Added to TODO:
* Once we expand timestamptz to bigger than 8 bytes, there's essentially
---
Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
So if I understand you correctly you are planning to extend
Tom,
As far as I can tell, Dennis is planning slavish adherence to the spec,
which will mean that the datatype is unable to cope effectively with
daylight-savings issues. So I'm unconvinced that it will be very
helpful to you for remembering local time in addition to true
(universal) time.
Josh Berkus [EMAIL PROTECTED] writes:
The reason is simple: our current implementation, which does include DST,
does not include any provision for the exceptions to DST -- such as Arizona
Say what?
regression=# set timezone to 'MST7MDT';
SET
regression=# select now();
now
Tom,
regression=# set timezone to 'US/Arizona';
SET
regression=# select now();
now
---
2004-10-25 10:52:49.441559-07
Wow! When did that get fixed? How do I keep track of this stuff if you
guys keep fixing it? ;-)
Of course, it would be
Josh Berkus [EMAIL PROTECTED] writes:
regression=# set timezone to 'US/Arizona';
SET
regression=# select now();
now
---
2004-10-25 10:52:49.441559-07
Wow! When did that get fixed? How do I keep track of this stuff if you
guys keep fixing it? ;-)
Of
On Mon, 25 Oct 2004, Josh Berkus wrote:
Hmmm ... well, does the spec specifically prohibit DST, or just leave it
out?
It doesn't discuss it. According to the spec a timestamp with time zone is
a UTC value + a HH:MM offset from GMT. And intervals in the spec is either
a year-month value or a
Dennis,
It doesn't discuss it. According to the spec a timestamp with time zone is
a UTC value + a HH:MM offset from GMT. And intervals in the spec is either
a year-month value or a day-time value. One can only compare year-month
values with each other and day-time values with each other. So
Josh Berkus [EMAIL PROTECTED] writes:
It doesn't discuss it. According to the spec a timestamp with time zone is
a UTC value + a HH:MM offset from GMT. And intervals in the spec is either
a year-month value or a day-time value. One can only compare year-month
values with each other and
On Mon, 25 Oct 2004, Josh Berkus wrote:
Dennis,
It doesn't discuss it. According to the spec a timestamp with time zone is
a UTC value + a HH:MM offset from GMT. And intervals in the spec is either
a year-month value or a day-time value. One can only compare year-month
values with each
On Mon, 25 Oct 2004, Josh Berkus wrote:
Hour/Minute/Second/ms
Day/Week
Month/Year
And just when I pressed send on the previous mail I got the problem
:-)
--
/Dennis Björklund
---(end of broadcast)---
TIP 2: you can get off all lists at once
On Mon, 25 Oct 2004, Josh Berkus wrote:
Hour/Minute/Second/ms
Day/Week
Month/Year
This is embarrasing. I'm still a bit confused :-)
The standard treat days as a separate entry, it does not assume that a day
is 24 hours. It restricts the hour field to the interval 0-23 so one can
never have
On Mon, Oct 25, 2004 at 21:18:52 +0200,
Dennis Bjorklund [EMAIL PROTECTED] wrote:
On Mon, 25 Oct 2004, Josh Berkus wrote:
Hour/Minute/Second/ms
Day/Week
Month/Year
This is embarrasing. I'm still a bit confused :-)
The standard treat days as a separate entry, it does not assume
Dennis Bjorklund [EMAIL PROTECTED] writes:
The standard treat days as a separate entry, it does not assume that a day
is 24 hours.
SQL92 says
4.5.2 Intervals
There are two classes of intervals. One class, called year-month
intervals, has an express or implied
On Mon, 25 Oct 2004, Tom Lane wrote:
There are two classes of intervals. One class, called year-month
intervals, has an express or implied datetime precision that in-
cludes no fields other than YEAR and MONTH, though not both are
required. The other class,
Dennis,
An implementation like the one Tom (and I) want would start with
2004-10-09 10:00 PDT
and then after the addition one would get
2004-11-23 10:00:00 PST
Sounds like we're on the same page then.
The standard restrict the hour field to the interval 0-23, so there can
never be any
On Mon, 25 Oct 2004, Josh Berkus wrote:
The standard restrict the hour field to the interval 0-23, so there can
never be any compare between for example '1 day 1 hour' and '25 hours'.
This means that one can not add two intervals together to get a bigger
one but that it would still work
Josh Berkus [EMAIL PROTECTED] writes:
As long as we're willing to live with the understanding that +1day 1 hour may
produce a slightly different result than + 25 hours, I don't see the problem.
Right, which is exactly why we can't accept the spec's restriction that
the hour field be limited to
regression=# set timezone to 'US/Arizona';
SET
regression=# select now();
now
---
2004-10-25 10:52:49.441559-07
Wow! When did that get fixed? How do I keep track of this stuff if you
guys keep fixing it? ;-)
That's worked for ages. What doesn't work is this:
Dennis Bjorklund [EMAIL PROTECTED] writes:
So if I understand you correctly you are planning to extend the current
timestamp type to work with both named time zones and HH:MM ones? I didn't
think you wanted the last one since your plan was to store a UTC+OID where
the OID pointed to a named
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
That's worked for ages. What doesn't work is this:
usatest=# select current_timestamp at time zone 'US/Arizona';
ERROR: time zone us/arizona not recognized
Right, and similarly you can do
regression=# select '2004-10-25 21:32:33.430222
On Fri, 22 Oct 2004, Tom Lane wrote:
behavior. The spec says you can put a numeric-GMT-offset zone in and
get a numeric-GMT-offset zone out. We can do that and also support
named, possibly DST-aware zones.
So if I understand you correctly you are planning to extend the current
timestamp
On Thursday 21 October 2004 11:01, Dennis Bjorklund wrote:
On Thu, 21 Oct 2004, Tom Lane wrote:
I'm aware that there are aspects of the spec behavior that appear to
require that, but is it really an improvement over the implementation
we have?
Improvement and improvement. The actual time
Robert Treat [EMAIL PROTECTED] writes:
In a fit of early morning, pre-coffee thoughts, I'm thinking this might be
just what I've been looking for. In one of my apps we take calls from around
the country for customers and store the time that call came in. Unfortunately
we need to know things
On Fri, 22 Oct 2004, Tom Lane wrote:
As far as I can tell, Dennis is planning slavish adherence to the spec,
which will mean that the datatype is unable to cope effectively with
daylight-savings issues. So I'm unconvinced that it will be very
helpful to you for remembering local time in
On Fri, Oct 22, 2004 at 16:28:12 +0200,
Dennis Bjorklund [EMAIL PROTECTED] wrote:
On Fri, 22 Oct 2004, Tom Lane wrote:
As far as I can tell, Dennis is planning slavish adherence to the spec,
which will mean that the datatype is unable to cope effectively with
daylight-savings issues.
Dennis Bjorklund [EMAIL PROTECTED] writes:
And exactly what issues is it that you see? The only thing I can think of
is if you have a timestamp and then add an interval to it so we jump past
the daylight saving time change date. Then the new timestamp will keep the
old timezone data of say +01
On Fri, 22 Oct 2004, Tom Lane wrote:
At bottom, what I want to be able to do is say
'2004-10-22 10:50:16.916003 America/New_York'
Yes, that's what we said in the last mail and I think there is a value in
having something like this.
universal time and not the timezone spec. Why should
Dennis Bjorklund [EMAIL PROTECTED] writes:
You don't need to be satisfied with it. I think a type like the above
would be fine to have. It should however not be called TIMESTAMP WITH
TIME ZONE because there is already a definition of that type. We can not
hijack standard types.
Sure we can,
On Fri, 22 Oct 2004, Tom Lane wrote:
than having two different types (the idea of a GUC variable to choose
which one is selected by a given type name is just horrid).
That is needed no matter what change you do if you want old programs that
use the current timestamp with time zone to work.
Dennis Bjorklund [EMAIL PROTECTED] writes:
On Fri, 22 Oct 2004, Tom Lane wrote:
than having two different types (the idea of a GUC variable to choose
which one is selected by a given type name is just horrid).
That is needed no matter what change you do if you want old programs that
use the
That is needed no matter what change you do if you want old programs that
use the current timestamp with time zone to work. Today you don't get back
the same time zone as you insert, programs might depend on that.
[ shrug... ] We've made much larger changes than that in the name of
I've made a partial implementation of a datatype timestamp with time
zone as described in the sql standard. The current type timestamptz
does not store the time zone as a standard one should do. So I've made a
new type I've called timestampstdtz that does store the time zone as the
standard
Dennis Bjorklund [EMAIL PROTECTED] writes:
I've made a partial implementation of a datatype timestamp with time
zone as described in the sql standard. The current type timestamptz
does not store the time zone as a standard one should do.
I'm aware that there are aspects of the spec behavior
On Thu, 21 Oct 2004, Tom Lane wrote:
I've made a partial implementation of a datatype timestamp with time
zone as described in the sql standard. The current type timestamptz
does not store the time zone as a standard one should do.
I'm aware that there are aspects of the spec behavior
35 matches
Mail list logo
