On 2013-01-21, Steve Crawford wrote:
>
> Date/time is not trivial. The portions of the PostgreSQL manual dealing
> with those data types bear careful and thoughtful reading and rereading
> while you experiment at the same time in a psql terminal till it
> "clicks." And while some time issues ar
On 2013-01-21, Gavan Schneider wrote:
> On Monday, January 21, 2013 at 06:53, Adrian Klaver wrote:
>
> timezones I have been learning a lot from the side.
>
> Taking another tangent I would much prefer the default time to
> be 12:00:00 for the conversion of a date to timestamp(+/-timezone).
On 2013-01-21, Rich Shepard wrote:
>What is the behavior if a column data type is timestamptz but there is
> only the date portion available? There must be a default time; can that be
> defined?
No, if you don't specify the time 00:00 (midnight) is used.
if you don't specify a timezone it's l
On Monday, January 21, 2013 at 18:11, bgd39h5...@sneakemail.com
(Nathan Clayton nathanclayton-at-gmail.com |pg-gts/Basic|) wrote:
I only wish. I work with a transactional system from the 70s on
a daily basis that decided to store something like a "work date" and
"work time". The date changes wh
On 01/22/2013 09:37 AM, Gavin Flower wrote:
On 23/01/13 06:30, Gavan Schneider wrote:
On 01/21/2013 07:40 PM, Steve Crawford wrote:
[...]
(While I suppose some politician somewhere could decide that
"fall-back" could cross date boundaries, I am unaware of any place
that has ever done somethi
On 23/01/13 06:30, Gavan Schneider wrote:
On 01/21/2013 07:40 PM, Gavan Schneider wrote:
[...]
(While I suppose some politician somewhere could decide that
"fall-back" could cross date boundaries, I am unaware of any place
that has ever done something so pathological as to have the same date
On 01/21/2013 07:40 PM, Gavan Schneider wrote:
...
The points raised by Adrain have prompted some more research on my
part and I am intrigued to learn that on one day of the year in many
countries (e.g., Brazil) where daylight conversion happens over
midnight the local-time version of midnight
On 01/21/2013 08:56 PM, Gavan Schneider wrote:
On Monday, January 21, 2013 at 10:53, Steve Crawford wrote:
On 01/21/2013 02:48 PM, Gavan Schneider wrote:
Taking another tangent I would much prefer the default time to be
12:00:00 for the conversion of a date to timestamp(+/-timezone).
P
Monday, January 21, 2013, 8:56:38 PM, you wrote:
>>Except for days that are 23-hours long, or 25, or other (it's a big
>>world with all sorts of timezone rules).
>>
> The day's length may change but I don't believe there is
> anywhere that allows for the local time of day to equal or be
> greate
On Monday, January 21, 2013 at 15:33, Tom Lane wrote:
I think it is also arguably contrary to the SQL standard...
17) If TD is the datetime data type TIMESTAMP WITHOUT TIME ZONE,
then let TSP be the of TD.
b) If SD is a date, then the s hour,
minute, and second of TV are set to 0 (zero) and t
On Monday, January 21, 2013 at 10:53, Steve Crawford wrote:
On 01/21/2013 02:48 PM, Gavan Schneider wrote:
Taking another tangent I would much prefer the default time to
be 12:00:00 for the conversion of a date to timestamp(+/-timezone).
Propose: '2013-12-25'::timestamp ==> 2013-12-25 1
Adrian Klaver writes:
> If I have learned anything about dealing with dates and times, is that
> it is a set of exceptions bound together by a few rules. Every time you
> think you have the little rascals cornered, one gets away.
Yeah, that's for sure. Anyway, I think we are exceedingly unlike
On 01/21/2013 07:40 PM, Gavan Schneider wrote:
On Monday, January 21, 2013 at 12:06, Kevin Grittner wrote:
Well, the big problem here is in trying to use either version of
timestamp when what you really want is a date. It will be much
easier to get the right semantics if you use the date type
On Monday, January 21, 2013 at 12:06, Kevin Grittner wrote:
Adrian Klaver wrote: [Actually Gavan Schneider wrote this, don't blame Adrian :]
I see where my confusion lies. There are two proposals at work in the above:
"Taking another tangent I would much prefer the default time
to be 12:00:0
Adrian Klaver wrote:
> If I was following Gavan correctly, he wanted to have a single
> timestamp field to store calender dates and datetimes. In other
> words to cover both date only situations like birthdays and
> datetime situations like an appointment.
If that is actually true, it sounds like
On 01/21/2013 05:06 PM, Kevin Grittner wrote:
Adrian Klaver wrote:
I see where my confusion lies. There are two proposals at work in the above:
"Taking another tangent I would much prefer the default time to be
12:00:00 for the conversion of a date to timestamp(+/-timezone)"
"Propose: '2013-1
Adrian Klaver wrote:
> I see where my confusion lies. There are two proposals at work in the above:
>
> "Taking another tangent I would much prefer the default time to be
> 12:00:00 for the conversion of a date to timestamp(+/-timezone)"
>
> "Propose: '2013-12-25'::timestamp ==> 2013-12-25 12:0
On 01/21/2013 03:53 PM, Steve Crawford wrote:
On 01/21/2013 02:48 PM, Gavan Schneider wrote:
On Monday, January 21, 2013 at 06:53, Adrian Klaver wrote:
On 01/21/2013 11:27 AM, Tom Lane wrote:
Note that that default is local midnight according to your current
timezone setting (from which w
On 01/21/2013 03:53 PM, Steve Crawford wrote:
On 01/21/2013 02:48 PM, Gavan Schneider wrote:
On Monday, January 21, 2013 at 06:53, Adrian Klaver wrote:
On 01/21/2013 11:27 AM, Tom Lane wrote:
Note that that default is local midnight according to your current
timezone setting (from which w
On Tuesday, January 22, 2013 at 09:48, I wrote:
(and I did report it as a bug back then)
Didn't pick this up on my pre-post re-read bug report was
_NOT_ against PostgreSQL. It was some very early incarnations of
OSX iCal, etc. which showed this behaviour.
Apologies for the noise/confusi
On 01/21/2013 02:48 PM, Gavan Schneider wrote:
On Monday, January 21, 2013 at 06:53, Adrian Klaver wrote:
On 01/21/2013 11:27 AM, Tom Lane wrote:
Note that that default is local midnight according to your current
timezone setting (from which we may guess that Adrian lives on the US
west co
On Monday, January 21, 2013 at 06:53, Adrian Klaver wrote:
On 01/21/2013 11:27 AM, Tom Lane wrote:
Note that that default is local midnight according to your current
timezone setting (from which we may guess that Adrian lives on the US
west coast, or somewhere in that general longitude).
On 01/21/2013 11:27 AM, Tom Lane wrote:
Adrian Klaver writes:
On 01/21/2013 07:26 AM, Rich Shepard wrote:
What is the behavior if a column data type is timestamptz but there is
only the date portion available? There must be a default time; can that be
defined?
Easy enough to test:
test=#
On 01/21/2013 11:27 AM, Tom Lane wrote:
Adrian Klaver writes:
On 01/21/2013 07:26 AM, Rich Shepard wrote:
What is the behavior if a column data type is timestamptz but there is
only the date portion available? There must be a default time; can that be
defined?
Easy enough to test:
test=#
On Mon, 21 Jan 2013, Tom Lane wrote:
Note that that default is local midnight according to your current
timezone setting (from which we may guess that Adrian lives on the US west
coast, or somewhere in that general longitude).
Yep. About 3 hours north of me.
Not sure you can change the def
Adrian Klaver writes:
> On 01/21/2013 07:26 AM, Rich Shepard wrote:
>> What is the behavior if a column data type is timestamptz but there is
>> only the date portion available? There must be a default time; can that be
>> defined?
> Easy enough to test:
> test=# create table ts_test(ts_fld time
On Mon, 21 Jan 2013, Adrian Klaver wrote:
Easy enough to test:
Thanks again, Adrian.
Rich
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 01/21/2013 07:26 AM, Rich Shepard wrote:
What is the behavior if a column data type is timestamptz but there is
only the date portion available? There must be a default time; can that be
defined?
Easy enough to test:
test=# create table ts_test(ts_fld timestamp with time zone);
CREATE TA
What is the behavior if a column data type is timestamptz but there is
only the date portion available? There must be a default time; can that be
defined?
Rich
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
29 matches
Mail list logo
