From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of hernan gonzalez
Sent: Sunday, June 26, 2011 3:57 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] to_timestamp() and timestamp without time zone
An analogy: a "localtim
On Sunday, June 26, 2011 12:57:15 pm hernan gonzalez wrote:
>
> An instant is a point in the universal time, it's a physical concept,
> unrelated to world calendars. The time point at which the man first landed
> on the moon is an instant, as is the moment at which my server restarted.
> It i
On Sunday, June 26, 2011 1:36:32 pm hernan gonzalez wrote:
> > You might want to review the Theories of Relativity, which pretty much
> > blew away
> > the notion of an absolute time and introduced the notion of frame of
> > reference
> > for time.
>
> Well, I give up.
As it happens I am currentl
On Sunday, June 26, 2011 12:57:15 pm hernan gonzalez wrote:
>
> An instant is a point in the universal time, it's a physical concept,
> unrelated to world calendars. The time point at which the man first landed
> on the moon is an instant, as is the moment at which my server restarted.
> It is no
>
>
> You might want to review the Theories of Relativity, which pretty much blew
> away
> the notion of an absolute time and introduced the notion of frame of
> reference
> for time.
>
>
Well, I give up.
--
Hernán J. González
http://hjg.com.ar/
On Sunday, June 26, 2011 12:57:15 pm hernan gonzalez wrote:
>
> An instant is a point in the universal time, it's a physical concept,
> unrelated to world calendars. The time point at which the man first landed
> on the moon is an instant, as is the moment at which my server restarted.
> It is no
On Friday, June 24, 2011 10:37:43 am hernan gonzalez wrote:
> > As I understand it, documentation patches are welcomed:)
>
> I'd indeed wish some radical changes to the documentation.
>
> To start with, the fundamental data type names are rather misleading; SQL
> standard sucks here, true, but Po
On Sat, Jun 25, 2011 at 3:56 AM, David Johnston wrote:
> First: I would suggest your use of “Local Time” is incorrect and that you
> would be better off thinking of it as “Abstract Time”. My responses below
> go into more detail but in short you obtain a “Local” time by “Localizing”
> and “Abstr
First: I would suggest your use of "Local Time" is incorrect and that you
would be better off thinking of it as "Abstract Time". My responses below
go into more detail but in short you obtain a "Local" time by "Localizing"
and "Abstract" time. The process of "Localization" requires a relevant
"Lo
> I meant that time-calculations themselves have lots of issues and
subtleties.
Fair enough, and I agree there is no magic API to solve the difficulties of
adapting rational, logic based systems to a Calendar system last edited by
the Pope and based upon the imperfect movement of Sol relative to E
> As I understand it, documentation patches are welcomed:)
I'd indeed wish some radical changes to the documentation.
To start with, the fundamental data type names are rather misleading; SQL
standard sucks here, true, but Postgresql also has its idiosincracies, and
the docs do not help much:
ht
On 06/23/2011 02:45 PM, David Johnston wrote:
...
As for "Time handling has lots of subtleties that take time to digest"; a
good programmer and API do their best to minimize the number of hidden
subtleties to be learned
I meant that time-calculations themselves have lots of issues and
subt
On Thursday, June 23, 2011 6:18:18 pm David Johnston wrote:
> Also, is this coercion noted in the documentation anywhere? I looked in
> the obvious locations (Data Type, Function, Appendix B). There should
> probably be something obvious, in the Data Type section, like:
>
> "When a Time Stamp w
>
> Possibly:
> test=> select (to_date('30/12/2007','DD/MM/') +
> '00:30'::time)::timestamp;
>timestamp
> -
> 2007-12-30 00:30:00
> (1 row)
>
>
Great, so now I have to capture the date and time portion of the string
separately AND I need to use two parameters i
On Thursday, June 23, 2011 1:42:42 pm hernan gonzalez wrote:
> Fair enough: to_timestamp doesn't do what I want, I must resort to casting.
>
> But it's rather unfortunate that a to_timestamp() function doesnt actually
> parse a "timestamp" (which, is a alias to "timestamp without timezone", at
>
> -Original Message-
> >
> > Every feature and function in PostgreSQL is "potentially dangerous"
> > - understanding them and using them correctly is the responsibility
> > of the programmer. Time handling has lots of subtleties that take
> > time to digest
> >
> >
> > Than
>
>
> Every example here starts, at its core, with to_timestamp. That function
> returns a timestamp *with* time zone so of-course the current timezone
> setting will influence it. Stop using it - it doesn't do what you want.
>
> If you cast directly to a timestamp *without* time zone you can take
On Thu, 2011-06-23 at 13:26 -0700, Adrian Klaver wrote:
> On 06/23/2011 01:07 PM, Steve Crawford wrote:
> > On 06/23/2011 12:30 PM, hernan gonzalez wrote:
> >>
> >>
> >> On Thu, Jun 23, 2011 at 4:15 PM, Adrian Klaver
> >> mailto:adrian.kla...@gmail.com>> wrote:
> >>
> >> On 06/23/2011 11:40 AM
On 06/23/2011 01:07 PM, Steve Crawford wrote:
On 06/23/2011 12:30 PM, hernan gonzalez wrote:
On Thu, Jun 23, 2011 at 4:15 PM, Adrian Klaver
mailto:adrian.kla...@gmail.com>> wrote:
On 06/23/2011 11:40 AM, hernan gonzalez wrote:
Rather than being not viable, I'd argue that is is no
On 06/23/2011 12:30 PM, hernan gonzalez wrote:
On Thu, Jun 23, 2011 at 4:15 PM, Adrian Klaver
mailto:adrian.kla...@gmail.com>> wrote:
On 06/23/2011 11:40 AM, hernan gonzalez wrote:
Rather than being not viable, I'd argue that is is not correct.
Rather, a simple dir
On Thu, Jun 23, 2011 at 4:15 PM, Adrian Klaver wrote:
> On 06/23/2011 11:40 AM, hernan gonzalez wrote:
>
>>Rather than being not viable, I'd argue that is is not correct.
>>Rather, a simple direct cast will suffice:
>>'2011-12-30 00:30:00'::timestamp without time zone
>>
>>
>> That wo
On 06/23/2011 11:40 AM, hernan gonzalez wrote:
Rather than being not viable, I'd argue that is is not correct.
Rather, a simple direct cast will suffice:
'2011-12-30 00:30:00'::timestamp without time zone
That works only for that particular format. The point is that, for
example, i
> Rather than being not viable, I'd argue that is is not correct. Rather, a
> simple direct cast will suffice:
> '2011-12-30 00:30:00'::timestamp without time zone
>
That works only for that particular format. The point is that, for example,
if I have some local date time
stored as a string in ot
On 06/23/2011 09:01 AM, hernan gonzalez wrote:
to_timestamp() returns a TIMESTAMP WITH TIME ZONE
Perhaps an alternative that returns a TIMESTAMP WITHOUT TIME ZONE
(which, BTW, is the default TIMESTAMP)
should be provided. Elsewhere, there is no direct-robust way of
parsing a TIMESTAMP WITHOU
There is some related discussion here
http://postgresql.1045698.n5.nabble.com/to-timestamp-returns-the-incorrect-result-for-the-DST-fall-over-time-td3327393.html
But it amounts to the same thing: TO_TIMESTAMP() is not apt for dealing with
plain TIMESTAMP
(without time zones).
Hence, there is no f
to_timestamp() returns a TIMESTAMP WITH TIME ZONE
Perhaps an alternative that returns a TIMESTAMP WITHOUT TIME ZONE (which,
BTW, is the default TIMESTAMP)
should be provided. Elsewhere, there is no direct-robust way of parsing
a TIMESTAMP WITHOUT TIME ZONE (which
represesents a "local date-time"
26 matches
Mail list logo
