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 1t2pEH-007ZyF-4B for pgsql-general@arkaria.postgresql.org; Mon, 21 Oct 2024 10:01:37 +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 1t2pEF-006KtQ-BV for pgsql-general@arkaria.postgresql.org; Mon, 21 Oct 2024 10:01:35 +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 1t2pEF-006KtI-0A for pgsql-general@lists.postgresql.org; Mon, 21 Oct 2024 10:01:35 +0000 Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t2pED-001zAW-5U for pgsql-general@lists.postgresql.org; Mon, 21 Oct 2024 10:01:34 +0000 Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-539d9fffea1so4069459e87.2 for ; Mon, 21 Oct 2024 03:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729504891; x=1730109691; darn=lists.postgresql.org; h=to:subject:message-id:date:from:reply-to:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=HyqKC2OZ7zSvd5FeP4gyl9lKRJCjaKjfWFLziYFxK8U=; b=UGrSDUiXpc9k2AdN8k3PVytjYo0b0HYnFCdsFJ1f1ug9CsMxlNUG6RCnROluLZkyRW wvDuP4F1/Pw1YGXUAdTDBb8hEVjhwPbzBD2yC0Etb21ywSbcnAGrz0iI3KSaeIUsvikr ft6baKmfE4n5gz3Ho09s8E9QHHYEVhzSu5c1Skv+rCcgpfY5VgbYwwQ1vxf9QenXYHwI JhJz8RXFas7KaBguHnKhKl5iCFnvzkKlCmN6O56Jqb8V9S2AOeKwzRnEDYA2qwK1AG9D LsiPnyfwM4VDUAw4bbiCidqDqzfSDv/qMfffASuorT+Mp1oUHjDvLCuVUqU7iIYSvK5+ /low== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729504891; x=1730109691; h=to:subject:message-id:date:from:reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HyqKC2OZ7zSvd5FeP4gyl9lKRJCjaKjfWFLziYFxK8U=; b=eseexIzQqVvThf+qLOVCPnwkaUQd0KxwUxSol/N85CmfXUopvPggRYGpP2DBBIo0Aj 5MsDbCH6Fedd/IR0aM39hG60oJXJY93Vcsbybf2vByAGA/5uTDrn2DUWuALgbU/clQfm 5ye3a68jFLOyuxVBUawnF+OdqjLeToCMtMM8no6877xIEclIgYSFB9ccflE5SIhHIoaF tKPKggi1oN3AI3egZNWfoiHBUHJjyQplxQMTK3pMbKj44pC2MWjjF2GAHo1tb1NiIoN6 0xwDEAW52dik0iKmOCSvtwgSZEpH1FmekGVXYdLH7ROHMfWTTof58zH1JpYb4nNs2zI/ F2xw== X-Gm-Message-State: AOJu0YzT8GA2dPecgoo+Y6Zs+8G+avP6n2TzHh5mRlBmfFJ26Ry1WrI1 ATEQsBl/5jy77t0VfQoWf78nw5GF47DJr/3bFOdehNIHfF5BEGc1MCSg0gwSy9cCKuQ6PGjLN96 7gGvhXZ8FDHcxbZCyrrr6u/IapqF2e3Tc X-Google-Smtp-Source: AGHT+IGpaxOdwPryU7pD6Og3pDeUATCP0xZNeWs1sSLMN46g+GAWaEcZvUIwhy49axeU+d6u+/cr5FWFtrTPsl2Wsxo= X-Received: by 2002:a05:6512:3c81:b0:539:e110:4d72 with SMTP id 2adb3069b0e04-53a1549b2f6mr5039239e87.56.1729504890919; Mon, 21 Oct 2024 03:01:30 -0700 (PDT) MIME-Version: 1.0 Reply-To: zarkonesmall@gmail.com From: Anatolii Smolianinov Date: Mon, 21 Oct 2024 12:01:19 +0200 Message-ID: Subject: Timezone: resolve $TZDIR in runtime To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000a921ea0624f9bcc8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a921ea0624f9bcc8 Content-Type: text/plain; charset="UTF-8" Hello, I was recently working with a project which embeds postgres into application. It uses binaries built for Debian, and configured to look for timezones in Debian's timezone folder /usr/share/zoneinfo/, which wasn't present on my system. I was thinking if it's possible to redefine it in runtime, and found that it is not possible: postgres support either compilation flag --with-system-tzdata or built-in tz file -- timezone/data/tzdata.zi. From the other hand, looking at src/timezone/pgtz.c#L54, it seems that timezone dir resolve happens in runtime, which means, it is possible to use $TZDIR environment variable or configuration option to achieve this without recompilation. Do you think it is a feasible thing to do? it would be very convenient for portable postgers builds. Thanks! --000000000000a921ea0624f9bcc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I was recently w= orking with a project which embeds postgres into application. It uses binar= ies built for Debian, and configured to look for timezones in Debian's = timezone folder /usr/share/zoneinfo/, which wasn't present on my system= .

I was thinking if it's possible to redef= ine it in runtime, and found that it is not possible: postgres support eith= er compilation flag --with-system-tzdata or built-in tz file --=C2=A0 timez= one/data/tzdata.zi. From the other hand, looking at src/timezone/pgtz.c#L54= , it seems that timezone dir resolve happens in runtime, which means, it is= possible to use $TZDIR environment variable or configuration option to ach= ieve this without recompilation.

Do you think= it is a feasible thing to do? it would be very convenient for portable pos= tgers builds.

Thanks!
--000000000000a921ea0624f9bcc8--