| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeremy Morton <admin(at)game-point(dot)net> |
| Cc: | Neil <neil(at)fairwindsoft(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Support for DATETIMEOFFSET |
| Date: | 2020-04-12 14:25:40 |
| Message-ID: | 13851.1586701540@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeremy Morton <admin(at)game-point(dot)net> writes:
> At just about every development shop I've worked for, I've seen
> developers use methods to get a local DateTime - both in the DB and in
> the code - such as DateTime.Now, and throw it at a DateTime field.
> Heck, even I've occasionally forgotten to use .UtcNow. With
> DateTimeOffset.Now, you can't go wrong. You get the UTC time, and the
> offset. I've taken to using it 100% of the time. It's just really handy.
It sounds like what you are describing is a client-side problem, not
a server issue. If you have such a thing in the client code, why
can't it readily be mapped to timestamptz storage in the server?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-04-12 14:55:20 | Re: Add "-Wimplicit-fallthrough" to default flags (was Re: pgsql: Support FETCH FIRST WITH TIES) |
| Previous Message | Robert Haas | 2020-04-12 14:19:07 | Re: pg_validatebackup -> pg_verifybackup? |