Обсуждение: Sybase to postgres Timestamp column
Hi All
When we are migrating from sybase to postgres, we are facing issues with Timestamp field format and not matching.
Sybase format: Jan 21 2026 5:35 PM
Please advise any workaround is there?
Regards
On 2026-01-21 14:53 +0100, SASIKUMAR Devaraj wrote:
> When we are migrating from sybase to postgres, we are facing issues
> with Timestamp field format and not matching.
> Sybase format: Jan 21 2026 5:35 PM
> Please advise any workaround is there?
I'm not familiar with Sybase. What issues are you facing? Please
provide more details such as database schema, error messages or expected
vs. actual results.
But Postgres should accept this timestamp format without issue:
SELECT 'Jan 21 2026 5:35 PM'::timestamp;
timestamp
---------------------
2026-01-21 17:35:00
(1 row)
--
Erik Wienhold
Erik Wienhold <ewie@ewie.name> writes:
> On 2026-01-21 14:53 +0100, SASIKUMAR Devaraj wrote:
>> When we are migrating from sybase to postgres, we are facing issues
>> with Timestamp field format and not matching.
>> Sybase format: Jan 21 2026 5:35 PM
> I'm not familiar with Sybase. What issues are you facing?
> But Postgres should accept this timestamp format without issue:
Yeah, I don't see a difficulty on the input side, so I'm guessing
the OP is wishing Postgres would output timestamps in that format.
Sorry, none of the built-in datestyle settings quite match that.
It's easy to replicate pretty closely using to_char():
postgres=# select to_char('Jan 21 2026 5:35 PM'::timestamp, 'Mon DD YYYY HH:MI PM');
to_char
----------------------
Jan 21 2026 05:35 PM
(1 row)
But wrapping all your timestamp output columns in to_char() might be
more trouble than fixing the client-side code to accept ISO format.
regards, tom lane
A couple of things to look out for in terms of dates that I have come across. First, date formats:
Aug 20 2004 4:23:07.786PM -- Postgres
Aug 20 2004 4:23:07:786PM -- Sybase
Aug 20 2004 4:23:07:786PM -- Sybase
Note the separator difference between seconds and milliseconds (dot vs. colon).
Second: date math is different for Sybase vs. Postgres. A difference in days in Sybase is computed by counting date thresholds crossed. If I recall, Postgres counts 24 hour periods crossed.
Hope this helps.
Tom Carroll
On Wednesday, January 21, 2026 at 10:07:00 AM EST, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Erik Wienhold <ewie@ewie.name> writes:
> On 2026-01-21 14:53 +0100, SASIKUMAR Devaraj wrote:
>> When we are migrating from sybase to postgres, we are facing issues
>> with Timestamp field format and not matching.
>> Sybase format: Jan 21 2026 5:35 PM
> I'm not familiar with Sybase. What issues are you facing?
> But Postgres should accept this timestamp format without issue:
Yeah, I don't see a difficulty on the input side, so I'm guessing
the OP is wishing Postgres would output timestamps in that format.
Sorry, none of the built-in datestyle settings quite match that.
It's easy to replicate pretty closely using to_char():
postgres=# select to_char('Jan 21 2026 5:35 PM'::timestamp, 'Mon DD YYYY HH:MI PM');
to_char
----------------------
Jan 21 2026 05:35 PM
(1 row)
But wrapping all your timestamp output columns in to_char() might be
more trouble than fixing the client-side code to accept ISO format.
regards, tom lane
> On 2026-01-21 14:53 +0100, SASIKUMAR Devaraj wrote:
>> When we are migrating from sybase to postgres, we are facing issues
>> with Timestamp field format and not matching.
>> Sybase format: Jan 21 2026 5:35 PM
> I'm not familiar with Sybase. What issues are you facing?
> But Postgres should accept this timestamp format without issue:
Yeah, I don't see a difficulty on the input side, so I'm guessing
the OP is wishing Postgres would output timestamps in that format.
Sorry, none of the built-in datestyle settings quite match that.
It's easy to replicate pretty closely using to_char():
postgres=# select to_char('Jan 21 2026 5:35 PM'::timestamp, 'Mon DD YYYY HH:MI PM');
to_char
----------------------
Jan 21 2026 05:35 PM
(1 row)
But wrapping all your timestamp output columns in to_char() might be
more trouble than fixing the client-side code to accept ISO format.
regards, tom lane