-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tom Lane wrote:
| Stuart Bishop <[EMAIL PROTECTED]> writes:
|
|>I'm trying to determine the best way of saying 'The current time in UTC
|>with no time zone information'.
|
|
| Isn't that a contradiction in terms?
Not at all - I want 'now' in UTC time without the extra backage of the
timezone information, since it is a well known fact. The functionality
of python's datetime.utcnow() or time.gmtime() basically. I can get
this, but it looks a bit ugly and confusing. I'll probably solve this
using a stored procedure.
| I *think* maybe what you want is to SET TIMEZONE = 'UTC' and then
| stop worrying about it. But anyone who is worried about timezones
| and yet is storing his data in timestamp-without-time-zone columns
| probably needs to reconsider exactly what his data represents.
| What is it that you actually want to store, and how do you want
| it presented?
I've got that set on the production server - this is mainly to ensure
that developers on their local instances are catered for and to make
things explicit. It makes the other developers more aware of what is
going on rather than things just accidently working in most cases. We
are a Python house and not a Perl house in other words :-)
How much overhead is there in storing a timestamp with timezone as
opposed to one without? You would need an extra few bits for the offset
but I don't know if that affects the total number of bytes to store it.
- --
Stuart Bishop <[EMAIL PROTECTED]>
http://www.stuartbishop.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBblAhAfqZj7rGN0oRAhhcAJ9c9o8Q6gK900U4hwqEjg/3bTyHIgCfY9x6
pMp+Iw3Yxrck0jIZCUz8ryk=
=mQ+L
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
