X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 2805D545EE for ; Fri, 4 Mar 2005 15:29:13 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 93644-09 for ; Fri, 4 Mar 2005 15:29:06 +0000 (GMT) Received: from www.onnet.cc (unknown [204.31.68.132]) by svr1.postgresql.org (Postfix) with ESMTP id 343A554580 for ; Fri, 4 Mar 2005 15:29:05 +0000 (GMT) Received: from 192.168.0.3 by www.onnet.cc (Sambar SMTPD); id s20050304082909.7285; Fri, 04 Mar 2005 08:29:09 Message-ID: <42287EC5.8090301@kensystem.com> Date: Fri, 04 Mar 2005 08:29:09 -0700 From: Ken Johanson User-Agent: Mozilla Thunderbird 1.0 (Windows/20050131) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-sql@postgresql.org Cc: andrew@supernews.com Subject: Re: definative way to place secs from epoc into timestamp References: <1109780719.28180.86.camel@bretsony> <13089.1109793126@sss.pgh.pa.us> <1109794066.27857.100.camel@bretsony> <13466.1109795186@sss.pgh.pa.us> <1109828560.27905.137.camel@bretsony> <2bf00b6e6300e2c76bc3c09fa89e7913@myrealbox.com> <1109834845.27905.147.camel@bretsony> <1109915231.28180.182.camel@bretsony> <42287CB8.7040600@kensystem.com> In-Reply-To: <42287CB8.7040600@kensystem.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.121 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200503/61 X-Sequence-Number: 20540 > > Unix time stamps, short (int) or long res, are always supposed to GMT > based, as far as I know - I never seen anything different, except maybe > in homebrew software. So it should be both calendar and P.I.T. And you > wouldn't need the TZ storage if the date-number and number-> translation > itself takes the TZ arg so that it can localize the Human String for you. > > Ken > In fact, I would suggest that if there is any function, or field, that takes a TZ-less argument (*especially* if it takes only the number), that its name should be made to contain 'UTC' so clearly disambiguate whats its intended use for (since zone-less values/fields SHOULD be regarded as UTC) - Otherwise, some users will place epoch numbers adjusted for the their timezone in the field (and even with daylight saving offsets applies, somewhat amusingly but wrong). So then two different users are using the exact same datatype for inconsistent types. (just a concern for interoperability, user awareness, and when an employee comes on-board and has to deal with bad legacy)