pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix edge-case behavior of pg_next_dst_boundary(). 5+ messages / 1 participants [nested] [flat]
* pgsql: Fix edge-case behavior of pg_next_dst_boundary(). @ 2012-04-25 21:26 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2012-04-25 21:26 UTC (permalink / raw) To: pgsql-committers Fix edge-case behavior of pg_next_dst_boundary(). Due to rather sloppy thinking (on my part, I'm afraid) about the appropriate behavior for boundary conditions, pg_next_dst_boundary() gave undefined, platform-dependent results when the input time is exactly the last recorded DST transition time for the specified time zone, as a result of fetching values one past the end of its data arrays. Change its specification to be that it always finds the next DST boundary *after* the input time, and adjust code to match that. The sole existing caller, DetermineTimeZoneOffset, doesn't actually care about this distinction, since it always uses a probe time earlier than the instant that it does care about. So it seemed best to me to change the API to make the result=1 and result=0 cases more consistent, specifically to ensure that the "before" outputs always describe the state at the given time, rather than hacking the code to obey the previous API comment exactly. Per bug #6605 from Sergey Burladyan. Back-patch to all supported versions. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/c62b8eaae11aaa69a2b71bc63f9f78ca72eb412c Modified Files -------------- src/timezone/localtime.c | 23 ++++++++++++----------- 1 files changed, 12 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix edge-case behavior of pg_next_dst_boundary(). @ 2012-04-25 21:26 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2012-04-25 21:26 UTC (permalink / raw) To: pgsql-committers Fix edge-case behavior of pg_next_dst_boundary(). Due to rather sloppy thinking (on my part, I'm afraid) about the appropriate behavior for boundary conditions, pg_next_dst_boundary() gave undefined, platform-dependent results when the input time is exactly the last recorded DST transition time for the specified time zone, as a result of fetching values one past the end of its data arrays. Change its specification to be that it always finds the next DST boundary *after* the input time, and adjust code to match that. The sole existing caller, DetermineTimeZoneOffset, doesn't actually care about this distinction, since it always uses a probe time earlier than the instant that it does care about. So it seemed best to me to change the API to make the result=1 and result=0 cases more consistent, specifically to ensure that the "before" outputs always describe the state at the given time, rather than hacking the code to obey the previous API comment exactly. Per bug #6605 from Sergey Burladyan. Back-patch to all supported versions. Branch ------ REL9_1_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/bf0d462a9d85037558861d9c6d50d2eaa284cc34 Modified Files -------------- src/timezone/localtime.c | 23 ++++++++++++----------- 1 files changed, 12 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix edge-case behavior of pg_next_dst_boundary(). @ 2012-04-25 21:26 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2012-04-25 21:26 UTC (permalink / raw) To: pgsql-committers Fix edge-case behavior of pg_next_dst_boundary(). Due to rather sloppy thinking (on my part, I'm afraid) about the appropriate behavior for boundary conditions, pg_next_dst_boundary() gave undefined, platform-dependent results when the input time is exactly the last recorded DST transition time for the specified time zone, as a result of fetching values one past the end of its data arrays. Change its specification to be that it always finds the next DST boundary *after* the input time, and adjust code to match that. The sole existing caller, DetermineTimeZoneOffset, doesn't actually care about this distinction, since it always uses a probe time earlier than the instant that it does care about. So it seemed best to me to change the API to make the result=1 and result=0 cases more consistent, specifically to ensure that the "before" outputs always describe the state at the given time, rather than hacking the code to obey the previous API comment exactly. Per bug #6605 from Sergey Burladyan. Back-patch to all supported versions. Branch ------ REL9_0_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/b0f24b5626727f81ecd7024ed5cefbaa336c8100 Modified Files -------------- src/timezone/localtime.c | 23 ++++++++++++----------- 1 files changed, 12 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix edge-case behavior of pg_next_dst_boundary(). @ 2012-04-25 21:26 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2012-04-25 21:26 UTC (permalink / raw) To: pgsql-committers Fix edge-case behavior of pg_next_dst_boundary(). Due to rather sloppy thinking (on my part, I'm afraid) about the appropriate behavior for boundary conditions, pg_next_dst_boundary() gave undefined, platform-dependent results when the input time is exactly the last recorded DST transition time for the specified time zone, as a result of fetching values one past the end of its data arrays. Change its specification to be that it always finds the next DST boundary *after* the input time, and adjust code to match that. The sole existing caller, DetermineTimeZoneOffset, doesn't actually care about this distinction, since it always uses a probe time earlier than the instant that it does care about. So it seemed best to me to change the API to make the result=1 and result=0 cases more consistent, specifically to ensure that the "before" outputs always describe the state at the given time, rather than hacking the code to obey the previous API comment exactly. Per bug #6605 from Sergey Burladyan. Back-patch to all supported versions. Branch ------ REL8_4_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/6b87144323fe4cf920ea4d095cce93a84c9b8922 Modified Files -------------- src/timezone/localtime.c | 23 ++++++++++++----------- 1 files changed, 12 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix edge-case behavior of pg_next_dst_boundary(). @ 2012-04-25 21:26 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 5+ messages in thread From: Tom Lane @ 2012-04-25 21:26 UTC (permalink / raw) To: pgsql-committers Fix edge-case behavior of pg_next_dst_boundary(). Due to rather sloppy thinking (on my part, I'm afraid) about the appropriate behavior for boundary conditions, pg_next_dst_boundary() gave undefined, platform-dependent results when the input time is exactly the last recorded DST transition time for the specified time zone, as a result of fetching values one past the end of its data arrays. Change its specification to be that it always finds the next DST boundary *after* the input time, and adjust code to match that. The sole existing caller, DetermineTimeZoneOffset, doesn't actually care about this distinction, since it always uses a probe time earlier than the instant that it does care about. So it seemed best to me to change the API to make the result=1 and result=0 cases more consistent, specifically to ensure that the "before" outputs always describe the state at the given time, rather than hacking the code to obey the previous API comment exactly. Per bug #6605 from Sergey Burladyan. Back-patch to all supported versions. Branch ------ REL8_3_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/17fc5db766146c6144f808a8117aee9d7c7901d6 Modified Files -------------- src/timezone/localtime.c | 23 ++++++++++++----------- 1 files changed, 12 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2012-04-25 21:26 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2012-04-25 21:26 pgsql: Fix edge-case behavior of pg_next_dst_boundary(). Tom Lane <tgl@sss.pgh.pa.us> 2012-04-25 21:26 pgsql: Fix edge-case behavior of pg_next_dst_boundary(). Tom Lane <tgl@sss.pgh.pa.us> 2012-04-25 21:26 pgsql: Fix edge-case behavior of pg_next_dst_boundary(). Tom Lane <tgl@sss.pgh.pa.us> 2012-04-25 21:26 pgsql: Fix edge-case behavior of pg_next_dst_boundary(). Tom Lane <tgl@sss.pgh.pa.us> 2012-04-25 21:26 pgsql: Fix edge-case behavior of pg_next_dst_boundary(). Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox