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 1qA2T9-0003vU-8Z for pgsql-admin@arkaria.postgresql.org; Fri, 16 Jun 2023 05:57:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qA2T8-0001Ay-4z for pgsql-admin@arkaria.postgresql.org; Fri, 16 Jun 2023 05:57:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qA2T7-00018u-N1 for pgsql-admin@lists.postgresql.org; Fri, 16 Jun 2023 05:57:57 +0000 Received: from mail-yb1-xb2c.google.com ([2607:f8b0:4864:20::b2c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qA2T2-002iKV-W0 for pgsql-admin@lists.postgresql.org; Fri, 16 Jun 2023 05:57:57 +0000 Received: by mail-yb1-xb2c.google.com with SMTP id 3f1490d57ef6-bd61dd9a346so265869276.2 for ; Thu, 15 Jun 2023 22:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686895071; x=1689487071; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=Kd9x0l46FffSgAEMB00uoEDtmfmulX9NFhTlD4SJoI8=; b=O+0soYgCBlkJwL4Q6EtoV/RG8g8WL/V3vR5yA1oeTUDzoK9D94q9P61qJD5DkkXiKa 3kQed7TMYKBsLw4xIcwEvC6iEdGkuW9oKSpB378C9DT1J+FzraOBZBsU/b8c7F9uVNXv Q4x/2/wAj+EKNI6SCkITG8VhH8OwKnOg6pdodM5T1Ti1mXHzNOW16yswxMoP0rlynEOf +Xd77aCIwsGqDHVhWNhCDFNiVbabiSmxUGUq/Ts8Tc25uSlAFNtoc4sK9VTOC4wmXvuY h1MIPydLdt3/TMr0L5W1kpIvyayjIK4qFoqCxC9o4F/CQWENaLHXszIU2OgGM8YvG1Lc nJGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686895071; x=1689487071; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=Kd9x0l46FffSgAEMB00uoEDtmfmulX9NFhTlD4SJoI8=; b=Yw8heUTDZln5Fjlxn1AjWn5YD7C0lllXt3bAQEd6Gt8VUZD7pAkfOPmogWY3mFYUie lScOY7wxaXeEiGMaBkRvhL+gmKjwgImGC7oiyrxRgZhjgIwrF7KvYMvnTNq2xgGYuz9Y jyP7MeLzlTSxFVKDGBJaEHzUGnwE4mlOQqezLqdBkeUj8MyLaOuSUGEyHzDUodGks6sF 6bjW9/5lW9JP+O1z4HmN90jIcdaSkeLodg4LG8FPQVeQnKS0Deagw1whdshQNQ6M4SV9 XjKDUyfM0j1BkuqR95+6u263evYv89hBdLY7RsJaIxwKuba7bVb5DhAJmkfNBpaAry7X /41Q== X-Gm-Message-State: AC+VfDxbdP5nwtNtJpFxd8TkPNuVkVdH56gB+GX4L/WVEzs0VT78D/SP vw3YNrLLvCvX4+bkzTIJl8OBGXIh4XE= X-Google-Smtp-Source: ACHHUZ4miN3YD1gYrGbwoY8EAvqq+LOI6QgvpmJwPCeOA62HIRXmCNwlUfA+X4khYPmi7ESa3dtNyg== X-Received: by 2002:a25:ef0f:0:b0:bc8:363e:83ca with SMTP id g15-20020a25ef0f000000b00bc8363e83camr589121ybd.31.1686895071354; Thu, 15 Jun 2023 22:57:51 -0700 (PDT) Received: from ?IPV6:2600:1700:bd2c:b810:4188:bc8d:5074:7f11? ([2600:1700:bd2c:b810:4188:bc8d:5074:7f11]) by smtp.googlemail.com with ESMTPSA id f189-20020a2551c6000000b00be4f34d419asm26388ybb.37.2023.06.15.22.57.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jun 2023 22:57:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------wIdYqwikCvZRo2lWnyZyvD4x" Message-ID: <6f8c7499-597e-d2d5-4178-b79253da83fd@gmail.com> Date: Fri, 16 Jun 2023 00:57:50 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: Conversion from Number to Date Content-Language: en-US To: "pgsql-admin@lists.postgresql.org" References: <14F13EFA-4298-44FF-ABD8-4913FBDCB212@gmail.com> From: Ron In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------wIdYqwikCvZRo2lWnyZyvD4x Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Don't be afraid to change 25567.0 to a value that works.  And make sure to adjust for time zones!! postgres=# SELECT to_timestamp((44795.731708-25567.0)*86400) AT TIME ZONE 'UTC';          timezone --------------------------  2022-08-24 17:33:39.5712 (1 row) postgres=# SELECT to_timestamp((44795.731708-25567.0)*86400) AT TIME ZONE 'America/New_York';          timezone --------------------------  2022-08-24 13:33:39.5712 (1 row) postgres=# SELECT to_timestamp((44795.731708-25567.0)*86400) AT TIME ZONE 'EST';          timezone --------------------------  2022-08-24 12:33:39.5712 (1 row) On 6/16/23 00:48, M Sarwar wrote: > Hi Ron, > > I appreciate your response. > > > select  to_timestamp((( start_time::numeric (20, 11)) - 25567.0 ) * 86400) > > FROM  bronx.test_part_details_all_mcmz_4_cols > > limit 24 > > When I try the above, I am getting a difference of 2 days. > > 1 day could be due leap year 1900 discrepancy but I am unable to figure > out the additional 1 day difference. > > > Thanks, > > Sarwar > > > ---------------------------------------------------------------------------- > *From:* Ron > *Sent:* Friday, June 16, 2023 1:14 AM > *To:* pgsql-admin@lists.postgresql.org > *Subject:* Re: Conversion from Number to Date > Try using the epoch "1 Jan 1900".  An offset of 25567.0 /should/ adjust > the date by 70 years. > > postgres=# SELECT to_timestamp((44795.731708-25567.0)*86400); >         to_timestamp > ----------------------------- >  2022-08-24 12:33:39.5712-05 > (1 row) > > You'll have to jigger with time zones yourself. > > On 6/15/23 23:53, M Sarwar wrote: >> Hi Ed, >> My dates are from the year 2022. >> Thanks, >> Sarwar >> >> ---------------------------------------------------------------------------- >> *From:* Ed Sabol >> *Sent:* Friday, June 16, 2023 12:19 AM >> *To:* Pgsql-admin >> >> *Cc:* M Sarwar >> *Subject:* Re: Conversion from Number to Date >> On Jun 15, 2023, at 10:23 PM, M Sarwar >> wrote: >> > Output: >> > 478         "44795.7306776851" "44795.731708" 44795.73067768510         >> 44795.73170800000 >> > 479         "44795.58143" "44795.58246" 44795.58143000000         >> 44795.58246000000 >> > 480         "44795.5714184259" "44795.572495" 44795.57141842590         >> 44795.57249500000 >> > >> > During the data load from CSV files to the database, the above >> START_TIME and STOP_TIME date column data arrived as number value. >> > Now I need  to translate the START_TIME and STOP_TIME back to DATE format. >> > >> > I am unable to find any documentation or help from the internet. >> > >> > Does it make sense or did I mess up something? >> >> Where did your CSV files come from? Just guessing, but those look like >> Modified Julian Dates (MJD). See >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJulian_day%23Variants&data=05%7C01%7C%7Cac9d24caf0e04fc41a5c08db6e20ee68%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638224859933137067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oEqi9djHFoDxXIcEL7KPr%2BoA2GywVUb1uli7l5nEpz4%3D&reserved=0 >> >> 44795.731708 MJD corresponds to 1981-07-10 17:33:39 UTC. Is that the era >> your data is from? >> >> If you add 2400000.5 to an MJD value, you get the Julian Date (JD). >> >> If you then subtract 2440587.5 and multiply the result by 86400, you get >> Unix time (the number of seconds since January 1, 1970), excluding leap >> seconds. >> >> Putting those together means, if you subtract 40587 from those numbers >> and multiply by 86400 and then use the PostgreSQL function >> to_timestamp(), you can convert them to timestamps. >> >> # SET timezone='utc'; >> SET >> # SELECT to_timestamp((44795.731708 - 40587.0)*86400); >>         to_timestamp >> ----------------------------- >>  1981-07-10 17:33:39.5712+00 >> (1 row) >> >> Again, I'm just guessing as to what your START_TIME and STOP_TIME values >> mean. You should ask whomever gave you the CSV files. >> >> Hope this helps, >> Ed >> > > -- > Born in Arizona, moved to Babylonia. -- Born in Arizona, moved to Babylonia. --------------wIdYqwikCvZRo2lWnyZyvD4x Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Don't be afraid to change 25567.0 to a value that works.  And make sure to adjust for time zones!!

postgres=# SELECT to_timestamp((44795.731708-25567.0)*86400) AT TIME ZONE 'UTC';
         timezone         
--------------------------
 2022-08-24 17:33:39.5712
(1 row)

postgres=# SELECT to_timestamp((44795.731708-25567.0)*86400) AT TIME ZONE 'America/New_York';
         timezone         
--------------------------
 2022-08-24 13:33:39.5712
(1 row)

postgres=# SELECT to_timestamp((44795.731708-25567.0)*86400) AT TIME ZONE 'EST';
         timezone         
--------------------------
 2022-08-24 12:33:39.5712
(1 row)



On 6/16/23 00:48, M Sarwar wrote:
Hi Ron,

I appreciate your response.


select  to_timestamp((( start_time::numeric (20, 11)) - 25567.0 ) * 86400)

FROM  bronx.test_part_details_all_mcmz_4_cols

limit 24

 

When I try the above, I am getting a difference of 2 days.

 

1 day could be due leap year 1900 discrepancy but I am unable to figure out the additional 1 day difference.


Thanks,

Sarwar


From: Ron <ronljohnsonjr@gmail.com>
Sent: Friday, June 16, 2023 1:14 AM
To: pgsql-admin@lists.postgresql.org <pgsql-admin@lists.postgresql.org>
Subject: Re: Conversion from Number to Date
 
Try using the epoch "1 Jan 1900".  An offset of 25567.0 should adjust the date by 70 years.

postgres=# SELECT to_timestamp((44795.731708-25567.0)*86400);
        to_timestamp         
-----------------------------
 2022-08-24 12:33:39.5712-05
(1 row)

You'll have to jigger with time zones yourself.

On 6/15/23 23:53, M Sarwar wrote:
Hi Ed,
My dates are from the year 2022.
Thanks,
Sarwar

From: Ed Sabol <edwardjsabol@gmail.com>
Sent: Friday, June 16, 2023 12:19 AM
To: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Cc: M Sarwar <sarwarmd02@outlook.com>
Subject: Re: Conversion from Number to Date
 
On Jun 15, 2023, at 10:23 PM, M Sarwar <sarwarmd02@outlook.com> wrote:
> Output:
> 478         "44795.7306776851"       "44795.731708"                 44795.73067768510         44795.73170800000
> 479         "44795.58143"                   "44795.58246"                   44795.58143000000         44795.58246000000
> 480         "44795.5714184259"       "44795.572495"                 44795.57141842590         44795.57249500000
> 
> During the data load from CSV files to the database, the above START_TIME and STOP_TIME date column data arrived as number value.
> Now I need  to translate the START_TIME and STOP_TIME back to DATE format.
>
> I am unable to find any documentation or help from the internet.
> 
> Does it make sense or did I mess up something?

Where did your CSV files come from? Just guessing, but those look like Modified Julian Dates (MJD). See https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FJulian_day%23Variants&data=05%7C01%7C%7Cac9d24caf0e04fc41a5c08db6e20ee68%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638224859933137067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oEqi9djHFoDxXIcEL7KPr%2BoA2GywVUb1uli7l5nEpz4%3D&reserved=0
44795.731708 MJD corresponds to 1981-07-10 17:33:39 UTC. Is that the era your data is from?

If you add 2400000.5 to an MJD value, you get the Julian Date (JD).

If you then subtract 2440587.5 and multiply the result by 86400, you get Unix time (the number of seconds since January 1, 1970), excluding leap seconds.

Putting those together means, if you subtract 40587 from those numbers and multiply by 86400 and then use the PostgreSQL function to_timestamp(), you can convert them to timestamps.

# SET timezone='utc';
SET
# SELECT to_timestamp((44795.731708 - 40587.0)*86400);
        to_timestamp        
-----------------------------
 1981-07-10 17:33:39.5712+00
(1 row)

Again, I'm just guessing as to what your START_TIME and STOP_TIME values mean. You should ask whomever gave you the CSV files.

Hope this helps,
Ed


--
Born in Arizona, moved to Babylonia.

--
Born in Arizona, moved to Babylonia.
--------------wIdYqwikCvZRo2lWnyZyvD4x--