Thread

  1. Feature freeze timezone change request

    Jelte Fennema-Nio <postgres@jeltef.nl> — 2026-03-18T23:07:29Z

    I was notified that the tentative feature freeze timestamp is on the
    wiki[1] as: April 8, 2026 0:00 UTC-12
    
    I request that the final feature freeze timestamp be set to 0:00 UTC,
    not 0:00 UTC-12. The comitfest app currently only supports dates as
    the start/end of a commitfest, not datetimes. By using 0:00 UTC I (or
    anyone else with admin access) can simply fill in the last day of the
    commitfest, and the commitfest will be automatically closed when that
    day ends in UTC.
    
    PS. I love that we're not using AoE anymore[2]
    
    [1]: https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
    [2]: https://www.postgresql.org/message-id/flat/Z_U0fUvVkXOZmRVV%40momjian.us
    
    
    
    
  2. Re: Feature freeze timezone change request

    Robert Haas <robertmhaas@gmail.com> — 2026-03-18T23:17:38Z

    On Wed, Mar 18, 2026 at 7:07 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
    > I was notified that the tentative feature freeze timestamp is on the
    > wiki[1] as: April 8, 2026 0:00 UTC-12
    >
    > I request that the final feature freeze timestamp be set to 0:00 UTC,
    > not 0:00 UTC-12.
    
    +1.
    
    > The comitfest app currently only supports dates as
    > the start/end of a commitfest, not datetimes. By using 0:00 UTC I (or
    > anyone else with admin access) can simply fill in the last day of the
    > commitfest, and the commitfest will be automatically closed when that
    > day ends in UTC.
    
    But not for this reason. It would be fine if the CF app closed the CF
    twelve hours before or after the actual feature freeze. But using UTC
    for everything is way less confusing, IMHO.
    
    > PS. I love that we're not using AoE anymore[2]
    
    +1
    
    -- 
    Robert Haas
    EDB: http://www.enterprisedb.com
    
    
    
    
  3. Re: Feature freeze timezone change request

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-19T00:40:55Z

    Robert Haas <robertmhaas@gmail.com> writes:
    > On Wed, Mar 18, 2026 at 7:07 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
    >> I was notified that the tentative feature freeze timestamp is on the
    >> wiki[1] as: April 8, 2026 0:00 UTC-12
    >> I request that the final feature freeze timestamp be set to 0:00 UTC,
    >> not 0:00 UTC-12.
    
    > +1.
    
    I think the UTC-12 business is left over from when we defined it as
    AoE, but we're not doing that anymore because it's too confusing.
    
    What we've been using lately for release freezes is noon UTC, which
    personally I'd prefer on the grounds that it's not as confusing
    which day is meant.
    
    			regards, tom lane
    
    
    
    
  4. Re: Feature freeze timezone change request

    Robert Haas <robertmhaas@gmail.com> — 2026-03-19T02:25:33Z

    On Wed, Mar 18, 2026 at 8:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
    > What we've been using lately for release freezes is noon UTC, which
    > personally I'd prefer on the grounds that it's not as confusing
    > which day is meant.
    
    Hmm, I kind of like that idea. I don't care that much in the end. But
    less confusing is better.
    
    -- 
    Robert Haas
    EDB: http://www.enterprisedb.com
    
    
    
    
  5. Re: Feature freeze timezone change request

    Peter Eisentraut <peter@eisentraut.org> — 2026-03-19T09:48:36Z

    On 19.03.26 00:07, Jelte Fennema-Nio wrote:
    > I was notified that the tentative feature freeze timestamp is on the
    > wiki[1] as: April 8, 2026 0:00 UTC-12
    > 
    > I request that the final feature freeze timestamp be set to 0:00 UTC,
    > not 0:00 UTC-12. The comitfest app currently only supports dates as
    > the start/end of a commitfest, not datetimes. By using 0:00 UTC I (or
    > anyone else with admin access) can simply fill in the last day of the
    > commitfest, and the commitfest will be automatically closed when that
    > day ends in UTC.
    
    I don't think the end of the commitfest and feature freeze need to be 
    the same thing.  The commitfest might as well end on 31 March or 1 April.
    
    
    
    
    
  6. Re: Feature freeze timezone change request

    Jelte Fennema-Nio <postgres@jeltef.nl> — 2026-03-19T12:28:07Z

    On Thu, 19 Mar 2026 at 10:48, Peter Eisentraut <peter@eisentraut.org> wrote:
    > I don't think the end of the commitfest and feature freeze need to be
    > the same thing.  The commitfest might as well end on 31 March or 1 April.
    
    I think it's fine for the feature freeze to end at a 12:00 UTC instead
    of 0:00 UTC. But I think the commitfest should end after the feature
    freeze, not before. Otherwise patches will show up as committed in
    PG20-1 when in fact they are part of the PG19 release.
    
    
    
    
  7. Re: Feature freeze timezone change request

    Andrew Dunstan <andrew@dunslane.net> — 2026-03-19T15:07:27Z

    On 2026-03-19 Th 8:28 AM, Jelte Fennema-Nio wrote:
    > On Thu, 19 Mar 2026 at 10:48, Peter Eisentraut <peter@eisentraut.org> wrote:
    >> I don't think the end of the commitfest and feature freeze need to be
    >> the same thing.  The commitfest might as well end on 31 March or 1 April.
    > I think it's fine for the feature freeze to end at a 12:00 UTC instead
    > of 0:00 UTC. But I think the commitfest should end after the feature
    > freeze, not before. Otherwise patches will show up as committed in
    > PG20-1 when in fact they are part of the PG19 release.
    >
    >
    
    
    Sure, close it on the 9th some time.
    
    
    cheers
    
    
    andrew
    
    
    --
    Andrew Dunstan
    EDB: https://www.enterprisedb.com
    
    
    
    
    
  8. Re: Feature freeze timezone change request

    Nathan Bossart <nathandbossart@gmail.com> — 2026-03-19T15:14:05Z

    On Wed, Mar 18, 2026 at 10:25:33PM -0400, Robert Haas wrote:
    > On Wed, Mar 18, 2026 at 8:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
    >> What we've been using lately for release freezes is noon UTC, which
    >> personally I'd prefer on the grounds that it's not as confusing
    >> which day is meant.
    > 
    > Hmm, I kind of like that idea. I don't care that much in the end. But
    > less confusing is better.
    
    +1 for April 8th, 12:00 UTC.
    
    -- 
    nathan
    
    
    
    
  9. Re: Feature freeze timezone change request

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-03-19T15:37:11Z

    On Wed, Mar 18, 2026 at 5:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
    > I think the UTC-12 business is left over from when we defined it as
    > AoE, but we're not doing that anymore because it's too confusing.
    
    Yeah -- I swapped it recently because I noticed it was still labeled
    AoE, and I didn't want anyone to have to rediscover last year's
    thread. It wasn't really meant to be an endorsement for UTC-12.
    
    > What we've been using lately for release freezes is noon UTC, which
    > personally I'd prefer on the grounds that it's not as confusing
    > which day is meant.
    
    +1 for 12:00 UTC.
    
    --Jacob
    
    
    
    
  10. Re: Feature freeze timezone change request

    Joe Conway <mail@joeconway.com> — 2026-03-19T16:08:18Z

    On 3/19/26 11:37, Jacob Champion wrote:
    > On Wed, Mar 18, 2026 at 5:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
    >> I think the UTC-12 business is left over from when we defined it as
    >> AoE, but we're not doing that anymore because it's too confusing.
    > 
    > Yeah -- I swapped it recently because I noticed it was still labeled
    > AoE, and I didn't want anyone to have to rediscover last year's
    > thread. It wasn't really meant to be an endorsement for UTC-12.
    > 
    >> What we've been using lately for release freezes is noon UTC, which
    >> personally I'd prefer on the grounds that it's not as confusing
    >> which day is meant.
    > 
    > +1 for 12:00 UTC.
    
    +1 seems reasonable and not likely to be misunderstood
    
    -- 
    Joe Conway
    PostgreSQL Contributors Team
    Amazon Web Services: https://aws.amazon.com
    
    
    
    
  11. Re: Feature freeze timezone change request

    Nathan Bossart <nathandbossart@gmail.com> — 2026-03-19T18:58:51Z

    On Thu, Mar 19, 2026 at 12:08:18PM -0400, Joe Conway wrote:
    > On 3/19/26 11:37, Jacob Champion wrote:
    >> On Wed, Mar 18, 2026 at 5:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
    >> > What we've been using lately for release freezes is noon UTC, which
    >> > personally I'd prefer on the grounds that it's not as confusing
    >> > which day is meant.
    >> 
    >> +1 for 12:00 UTC.
    > 
    > +1 seems reasonable and not likely to be misunderstood
    
    I updated the wiki page.  Shall we also remove the "(tentative)"?
    
    -- 
    nathan
    
    
    
    
  12. Re: Feature freeze timezone change request

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-19T19:03:36Z

    Nathan Bossart <nathandbossart@gmail.com> writes:
    > I updated the wiki page.  Shall we also remove the "(tentative)"?
    
    +1
    
    BTW, there is some weird caching issue with that page: I did not see
    the up-to-date version, even after multiple refreshes.  It wasn't
    till I noticed I wasn't logged into the wiki and corrected that
    that I saw your edit.
    
    			regards, tom lane
    
    
    
    
  13. Re: Feature freeze timezone change request

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-03-19T19:06:09Z

    On Thu, Mar 19, 2026 at 12:03 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
    > BTW, there is some weird caching issue with that page: I did not see
    > the up-to-date version, even after multiple refreshes.  It wasn't
    > till I noticed I wasn't logged into the wiki and corrected that
    > that I saw your edit.
    
    I've noticed that with other pages, but I assumed it was
    intentional/robot-related.
    
    --Jacob