Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lp4eC-00039R-D2 for pgsql-novice@arkaria.postgresql.org; Fri, 04 Jun 2021 07:53:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lp4eB-0001Bv-9t for pgsql-novice@arkaria.postgresql.org; Fri, 04 Jun 2021 07:53:39 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lp4eB-0001Bm-2v for pgsql-novice@lists.postgresql.org; Fri, 04 Jun 2021 07:53:39 +0000 Received: from mail-pf1-x431.google.com ([2607:f8b0:4864:20::431]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lp4e5-0004B4-HA for pgsql-novice@lists.postgresql.org; Fri, 04 Jun 2021 07:53:38 +0000 Received: by mail-pf1-x431.google.com with SMTP id u18so6851027pfk.11 for ; Fri, 04 Jun 2021 00:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FrlRVXdJzyCchZV9SNRjyebwWE5xHQKMZvwf1cfoZnM=; b=oIgQJ6JAgsZSrNWzw4aEX7xYnzFxwYjBr1NKh7pGKTO7Bz0LXygqiKOFrBH95gMKQy lxE5roa1+/xZnWB6oEkQvia+E8HoN2O0CQkfIgI9cyJKgtLufFCYGBJpm00K0uoF2Ldd Ra/HITJqKlHpzBLDWrCJEcFCPZkYE/NLCWREShMGn/6yx0eRwP01ONfqpgYFTrQMhuOY Pf595AAQ/0797GT5Snhsm0rAGuTSsqMsGfqn3Eb6qOL8YvIs43qeJoIzcpKz3UMEdXGx SD6ydE80+UZMFIbndCA7lyhcJRJ20fE+DH+RPO3+KOwGxiTWV3MDbIZuK9MSIylBQtBg VCaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FrlRVXdJzyCchZV9SNRjyebwWE5xHQKMZvwf1cfoZnM=; b=kIBlrkV8a3gOkoJ/TVbYTCe2qwZInGW3RZLpzS4QgaR5JnwRVrRggtVcfL1A94hwaH j4FrF47ccf2+23FB2kkDNUIUvf4wBV+U/dD9G99OWKIG11B6onlJCNrCAs/ML5Y03Xo6 7LERmrD2en8dOXsjB244T+pBCbTVCp9NIsy5aywsKrhlAb8lb3Eefpbd95838cFFiPt9 Mm6bu6Xs4vJ9GPzjETmB7SDRy6VgcFVnhUdlE+VOS+d4AQDB4L0WPAJwtqkz3hA6V9X9 oelXHgtIio4YOakIO4SmzRDAXLGYX8A8xDAX4frFm6LC8mIiOua+elD3V1KDRK2wTynt MleQ== X-Gm-Message-State: AOAM531UYBW7HDesjYxE2sHu/R7U/dGCKjbA7oL+ojCQJr7dlLQr7Lkc tTgpBHsuESyGvSZFKFepdpqjrLoF/q0TnEyyf45WB5F5UjI= X-Google-Smtp-Source: ABdhPJzM39WBytTY/BhBfXuo9qfnDTvmlZtDWoa7qPduC4dIo/g0I4HbdMdXwmLiNyosZDsHhQcZnLdpPHDB4zEXMZw= X-Received: by 2002:a05:6a00:14d0:b029:2cf:ee47:dfd9 with SMTP id w16-20020a056a0014d0b02902cfee47dfd9mr3250203pfu.31.1622793211601; Fri, 04 Jun 2021 00:53:31 -0700 (PDT) MIME-Version: 1.0 From: Jonas Gassenmeyer Date: Fri, 4 Jun 2021 09:53:20 +0200 Message-ID: Subject: NOW() function in combination with SET timezone To: pgsql-novice@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000ebe89105c3ebfc64" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ebe89105c3ebfc64 Content-Type: text/plain; charset="UTF-8" Hello everyone, i have a background in Oracle and it seems that dealing with time zones is treated a bit different in PostgreSQL. I started experimenting with NOW() and timezone settings and understand that (at least the *display* in the client) can be changed by the SET command. What I don't understand is, what data/info will be sent from my client to the database server when... 1. ...storing a timestamp value in a column (INSERT) 2. ...comparing now() with another column in the WHERE clause For 1.) it would help if I have similar options like the DUMP() function in Oracle (is there an equivalent that would give me a hint what has been *physically* stored in a column?) For 2.) it would help if You could confirm my current understanding: - Let's assume my client has set the timezone to Tokyo and the server is using UTC. - Even if calling NOW() and the display in my client is Tokyo time, once I send data to the server my timestamp would get converted to the timezone of the server. - For further comparison with any time stamp columns in a table it would use the converted timestamp (UTC timezone of the database server). - It would not make a difference if I compare NOW() to a column of type timestamp instead of timestampTZ (assuming that I know what timezone was used to insert into the column) Thank You so much in advance and happy Friday! --- Jonas --000000000000ebe89105c3ebfc64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,
i have a background in Orac= le and it seems that dealing with time zones is treated a bit different in = PostgreSQL. I started experimenting with NOW() and timezone settings and un= derstand that (at least the *display* in the client) can be changed by the = SET command. What I don't understand is, what data/info will be sent fr= om my client to the database server when...
  1. ...storin= g a timestamp value in a column (INSERT)
  2. ...comparing now() wit= h another column in the WHERE clause
For 1.) it would help if= I have similar options like the DUMP() function in Oracle (is there an equ= ivalent that would give me a hint what has been *physically* stored in a co= lumn?)

For 2.) it would help if You could confirm = my current understanding:
  • Let's assume my client has = set the timezone to Tokyo and the server is using UTC.
  • Even if call= ing NOW() and the display in my client is Tokyo time, once I send data to t= he server my timestamp would get converted to the timezone of the server.
  • For further comparison with any time stamp columns in a table it wou= ld use the converted timestamp (UTC timezone of the database server).
  • <= li>It would not make a difference if I compare NOW() to a column of type ti= mestamp instead of timestampTZ (assuming that I know what timezone was used= to insert into the column)
Thank You so much in advance and = happy Friday!
---
Jonas =
--000000000000ebe89105c3ebfc64--