Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tcZ7V-0011EQ-8O for pgsql-general@arkaria.postgresql.org; Tue, 28 Jan 2025 00:06:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tcZ7R-00FbLl-ER for pgsql-general@arkaria.postgresql.org; Tue, 28 Jan 2025 00:06:17 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tcZ7R-00FbLd-1z for pgsql-general@lists.postgresql.org; Tue, 28 Jan 2025 00:06:17 +0000 Received: from mail-ot1-x332.google.com ([2607:f8b0:4864:20::332]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tcZ7N-001qWR-2E for pgsql-general@postgresql.org; Tue, 28 Jan 2025 00:06:16 +0000 Received: by mail-ot1-x332.google.com with SMTP id 46e09a7af769-7231e264735so727387a34.0 for ; Mon, 27 Jan 2025 16:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738022773; x=1738627573; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XfywPTviOiaQ+XUMPCJ+ju5TfgFDxRNRdIVQ5xIEBlI=; b=PWizg1+a7sWHzAXuUS2ezs/GKaeYZPfG0/Hht08raiisgrixefLZjilnf8Ur07olR7 LOQmBPFNSGB7jxZ/JmO49U9c+CTeZMBNIOYPvq7mp6/cxwNsGBEkEa1gloT9UJrdk1uO uI8h2y1/HUO85wIexLDtYvi5h4riQKGYUsfVeFtSXMJu42SJSt/IsyTEfUiknoDulCZ0 VdEzGA8LVHbrhTKlobuXqUlKhvt9YbQFfMWkotZG49WPT4jDKu5yWLb81oFlp/X6ib9Y 317MoXP+XzaLcYNbKjhXeshTOwSTZVDbHgFY4f+RR1rZpD/2qDs6RTWwR9ATflLqU014 v7Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738022773; x=1738627573; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XfywPTviOiaQ+XUMPCJ+ju5TfgFDxRNRdIVQ5xIEBlI=; b=d1hOahzfVCgaHfBcF+g7tPAXgdVRZCllAhRyboJGtAB78yUrinqM5QU6StEi2IFHOm P4T290rTlpNcI6EkwMZ+IHS8vJrvoqFfmFIlOqsaNHJ24lHnM95ONSCZ9o7KWHMKzLmr Z7RNrsqHmr+coU01bnxxCw2G2ZgWINGPadVrPzN8ooOHa0EOFH4ZTAFlbR6zWJXZt8X5 zrgZ2hyz6RiDhb6hBhb+d5FIqNDmdyeFJjAGVGCGlnDWlkHB3nnwHjuuMlhb/Td3IxBo wfs9/qOdCpKnhkUbh6l5vc5IBUPMWvQ9JS16zFt7CLrd9Ip41bSXgmKWquMMPx5igeyR JO7Q== X-Gm-Message-State: AOJu0Yz0gsUh65BA1ru58LpP97C/7SiDtBrJWx87L0CZi/1UYqFUm3k7 Le9ycXki86z40TiKyS+dI7LONnX3llkmQYQ5nMR+4KRdxIDekWJmAFAh080sjpJ9lPHiaIyZOTn gqZEcqvIIip/ah5lLo9EDXsSZRnY= X-Gm-Gg: ASbGncu9neyFe72O/Ri+NexHpcFdpecL/KGWhx4psHPmoKOur7la7ZOx8pEVb1oqFr/ cFw+fprulyeoP8U3zmvAVHKeGfAgYBfV2PTDputDLs9007VE+xdd0AhzsWuZPsQ== X-Google-Smtp-Source: AGHT+IGiGo7FRaTKNoUqOCEYUH1oF3PRbhVTUIQ/XDjOl7JoPGcO1Es2LH8CCRzwFxK5p3TSE4nRLDO0eWlVWHROVho= X-Received: by 2002:a05:6870:1587:b0:29e:4525:fa5c with SMTP id 586e51a60fabf-2b1c0a0607emr9586769fac.2.1738022773431; Mon, 27 Jan 2025 16:06:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Thomas Munro Date: Tue, 28 Jan 2025 13:05:37 +1300 X-Gm-Features: AWEUYZmebzm-tksoJN5GYHJV_EThGUHwyPwq0EzSq0xEd0M86iTzytDLoW46bFk Message-ID: Subject: Re: Issues with EPOCH-s, TIMESTAMP(TZ)-s and leap seconds. To: Nem Tudom Cc: pgsql-general Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jan 28, 2025 at 10:02=E2=80=AFAM Nem Tudom wrote: > Any help, advice, recommendations, URL-s, references &c. appreciated. As others have said, we're using the POSIX AKA Unix time scale, as almost all general purpose computer systems do. It's based on the UTC time scale (the one that has SI seconds of fixed duration defined by caesium atoms, with extra seconds inserted by committee that should be displayed as eg 23:59:61 as required to stay within a certain tolerance of the variable-duration seconds implied by the earth's actual rotation divided by 86400, known as UT1 or something like that), except that in POSIX the leap seconds are ignored. There is a sort of discontinuous jump, or you might say that the second is compressed to a duration of 0. Systems that have good reasons to care about this stuff often use the TAI time scale (also SI seconds, but with no leap seconds and thus slowly falling out of sync with the earth's rotations), or the GPS time scale which is the same except offset by the number of leap seconds that had been decreed as of 1980 when they invented it and ignoring all new leap seconds after that. You need an up-to-date table of leap seconds to convert between time scales, and of course it'd be lossy on eg TAI->POSIX conversions, but not the reverse. I showed the bones of how you could do this in SQL here: https://www.postgresql.org/message-id/CA%2BhUKGLU9Don4YHnfdzn0eeWQsUu8GJDaL= iUAefLLT6%3DmmeGoQ%40mail.gmail.com The IERS inserts leap seconds at times that are not expected to interfere with business, so most people just don't care and the POSIX time scale is good enough. That's not always entirely successful: I've forgotten all the details but once a leap second was inserted at the moment the Japanese stock market opened, leading to confusion (looking at the table[1] I think it must have been one of the June ones where the 30th fell on a business day). As for how these jumps in the time scale really happen, there are various approaches including "smearing" the extra second over a period of time (ie making the neighbouring seconds shorter for a window of time) so that POSIX time drifts towards being in sync with UTC over a couple of hours or something; that works about as well as you'd expect with many different NTP (etc) implementations using different approaches that only rarely test these transitions, but again good enough for most stuff. The powers that be have agreed to stop adding UTC leap seconds after 2035, so UTC will eventually cease to be "coordinated" (the C) going forward, and have a fixed offset against TAI and GPS. The leap second table will effectively be fixed and only of interest for dealing with historical times 1972-2035. And just like TAI and GPS, it'll begin to drift out of sync with the earth's rotations without further adjustments, since it's based on SI seconds and the earth is a spinning chunk of wobbly stardust. (My memory of all that might be a little fuzzy and I know zilch about the science of it, but a couple of decades ago I worked on software that talked to a lot of stock exchanges and we had to worry about when certain things happened and think about smearing etc. In practice time zones were a far bigger source of stress... I recall a local government suddenly declaring a daylight savings change to suit a sporting event, etc...) [1] https://en.wikipedia.org/wiki/Leap_second