On Mon, 19 May 2025 at 19:34, Ee Durbin via tz <tz@iana.org> wrote:
PyCon US makes extensive use of software across an annoying number of online and offline systems. These include GNU/Linux servers, PostgreSQL databases, all web browsers, a mobile application, Raspberry Pis, iPads, Zebra printers, printed materials, and human brain matter. These systems persist year-over-year while our timezone does not. This timezone is proposed to provide a durable solution for ensuring agreement between these systems.
Hey, Ee. Welcome back to Pittsburgh and I hope it's been treating you well! I know that we crossed paths very briefly at the communty booths — possibly even between when you sent this and when it was released from the moderation queue — but amidst thousands of others and in radically different contexts, I'm sure it's all a bit of a blur. It's nice to finally e-(re)-meet you. I am sympathetic to the plight you describe and I do appreciate that there is a reasonably long history of "conference time". Over the years, I've heard anecdotes from friends involved in multi-city conference planning who have taken a similar approach to their internal (and sometimes even external) communications, deadlines, and scheduling throughout the planning process: Rather than wrangling changing time zones each cycle, they simply established permanently that "[Name of Conference] Time is defined as whatever the time is wherever the next [Name of Conference] is". While extending this pragmatic approach from human communications to the technology that inevitably underpins it does seem like a logical next step, I'm sorry to say that it's pretty firmly out of scope for inclusion in tz data proper. We aim only to cover civil time scales, which are generally those designated by civilian authorities, as observed *de facto* by those under such authorities' jurisdiction. See: https://data.iana.org/time-zones/data/theory.html#scope Further, I'm sure you can appreciate that establishing such a Zone for one conference would unavoidably open us up to requests from all of the many others, which is quite a level of "scope creep" which we understandably are not equipped to support. That said, on a purely technical level, you're free to create a Zone for your own use and, in fact, you've already done the data part of the work! FWIW, I maintain my own personal Zone which follows my own travels — and am excited to finally get to update it again soon! — but I don't actively use it anywhere, out of a personal preference for being able to make use of readily-available standard installations on new systems. But it seems that your balancing of concerns may very well be radically different. While we don't officially have a private-use namespace defined within our data, if you do ultimately choose to go down that path, you may find something like "Private/PyConUS" to be a more durable path in the longer term (not that we're likely to put a conflicting Zone in Etc). There may be others here on the list who could offer greater assistance on how best to incorporate such a private-use Zone into your systems' toolchains. Looking forward to hearing what you end up doing with this! While I appreciate and understand that this submission may appear to be a
gag/joke, I am sincere in this request and humbly request that it be considered with sincerity in kind.
How's that for sincerity? ;) It's got to be rough to be in the fairly unique position of hitting up against sharp corner cases so often. Thanks so much for all of your diligent work and consideration on how best to keep improving things for all the humans involved. I genuinely wish you and all the PyCon US organizers the very best. -- Tim Parenti