Lists: | pgsql-patches |
---|
From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | pgsql-patches(at)postgresql(dot)org |
Subject: | Release notes typo |
Date: | 2005-10-25 04:05:23 |
Message-ID: | 20051025040523.GA33423@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-patches |
"dates who's result" should be "dates whose result."
--
Michael Fuhr
Attachment | Content-Type | Size |
---|---|---|
release.patch | text/plain | 1.3 KB |
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Fuhr <mike(at)fuhr(dot)org> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Release notes typo |
Date: | 2005-10-25 04:17:52 |
Message-ID: | 9473.1130213872@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-patches |
Michael Fuhr <mike(at)fuhr(dot)org> writes:
> "dates who's result" should be "dates whose result."
It's still horrible English :-( A date hasn't got a result, much
less one that includes a daylight savings time adjustment period.
We should rewrite the entire paragraph. Maybe
Days that contain a daylight savings time adjustment are not 24
hours, but typically 23 or 25 hours. This change creates a
conceptual distinction between intervals of "so many days"
and intervals of "so many hours". Adding '1 day' to a timestamp
now gives the same local time on the next day even if a daylight
savings time adjustment occurs between, whereas adding '24 hours'
will give a different local time when this happens. For example:
<same example>
regards, tom lane
From: | Michael Fuhr <mike(at)fuhr(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Release notes typo |
Date: | 2005-10-25 04:58:35 |
Message-ID: | 20051025045835.GA33563@winnie.fuhr.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-patches |
On Tue, Oct 25, 2005 at 12:17:52AM -0400, Tom Lane wrote:
> Michael Fuhr <mike(at)fuhr(dot)org> writes:
> > "dates who's result" should be "dates whose result."
>
> It's still horrible English :-( A date hasn't got a result, much
> less one that includes a daylight savings time adjustment period.
Good point.
> We should rewrite the entire paragraph. Maybe
>
> Days that contain a daylight savings time adjustment are not 24
> hours, but typically 23 or 25 hours. This change creates a
> conceptual distinction between intervals of "so many days"
> and intervals of "so many hours". Adding '1 day' to a timestamp
> now gives the same local time on the next day even if a daylight
> savings time adjustment occurs between, whereas adding '24 hours'
> will give a different local time when this happens. For example:
Sounds reasonable.
BTW, I don't know what's correct in other countries, but in the US
it's officially "daylight saving time" (singular "saving").
http://tf.nist.gov/general/daylightsavingtime.html
Not that anybody actually says it that way ;-)
--
Michael Fuhr
(Who'd be happy to live on UTC and do away with timezones and DST altogether.)
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Michael Fuhr <mike(at)fuhr(dot)org> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Release notes typo |
Date: | 2005-10-25 15:12:48 |
Message-ID: | 200510251512.j9PFCmL27399@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-patches |
I updated the description differently:
Dates that contain a daylight savings time adjustment are not 24
hours, but typically 23 or 25 hours. This change allows numeric days
(not fixed 24-hour periods) to be added to dates which include
a daylight savings time adjustment period. Therefore, while in
previous releases <literal>1 day</> and <literal>24 hours</> were
interchangeable interval values, in this release they are treated
differently, e.g.
---------------------------------------------------------------------------
Michael Fuhr wrote:
> "dates who's result" should be "dates whose result."
>
> --
> Michael Fuhr
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073