Release notes typo

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