On Wed, Jul 24 2013, Russ Tyndall wrote:
> Baring the rest of the issues you might be experiencing with these layered
> systems, "2013-01-01 11:00:00" is considered timezoneless (ie: local zone of
> whatever computer is interpreting it). If you wish to insert "2013-01-01
> 04:00:00 UTC" the corre
On 7/24/2013 10:37 AM, Julien Danjou wrote:
Not really unfortunatelly, unless I've missed the obvious. I've still
have no clue on how to insert "2013-01-01 12:00:00 UTC" into PG. Your
first example inserted "2013-01-01 04:00:00 UTC", and the second
example inserted "2013-01-01 03:00:00 UTC". Th
On Wed, Jul 24 2013, Sabra Crolleton wrote:
Hi Sabra,
> Are you thinking that PG will allow you to have different timezones in your
> timestamp? If my understanding of PG is correct, it keeps everything in a
> single timezone - UTC. Then everything else is set using the offset. See,
> e.g. http:/
Julien,
Are you thinking that PG will allow you to have different timezones in your
timestamp? If my understanding of PG is correct, it keeps everything in a
single timezone - UTC. Then everything else is set using the offset. See,
e.g. http://www.postgresql.org/docs/9.1/static/datatype-datetime.h
On Wed, Jul 24 2013, Sabra Crolleton wrote:
> I use the local-time package with encode-timestamp to create the timestamp
> and just put that into the database.
>
> Function: local-time:encode-timestamp nsec sec minute hour day month year
> &key timezone offset into
>
> Returns a new timestamp inst
I use the local-time package with encode-timestamp to create the timestamp
and just put that into the database.
Function: local-time:encode-timestamp nsec sec minute hour day month year
&key timezone offset into
Returns a new timestamp instance corresponding to the specified time
elements. The of
