Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id E288E930E1E for ; Fri, 3 Aug 2012 15:40:27 -0300 (ADT) Received: from fep32.mx.upcmail.net ([62.179.121.50]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SxMnR-0000Ny-Ba for pgsql-performance@postgresql.org; Fri, 03 Aug 2012 18:40:27 +0000 Received: from edge03.upcmail.net ([192.168.13.238]) by viefep12-int.chello.at (InterMail vM.8.01.05.04 201-2260-151-105-20111014) with ESMTP id <20120803183747.RSZN20237.viefep12-int.chello.at@edge03.upcmail.net>; Fri, 3 Aug 2012 20:37:47 +0200 Received: from [192.168.0.101] ([89.134.225.226]) by edge03.upcmail.net with edge id iJdm1j0114tiMtV03JdmyL; Fri, 03 Aug 2012 20:37:47 +0200 X-SourceIP: 89.134.225.226 Message-ID: <501C1A79.8080707@shopzeus.com> Date: Fri, 03 Aug 2012 20:37:45 +0200 From: Laszlo Nagy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Steve Crawford CC: pgsql-performance@postgresql.org Subject: Re: [ADMIN] Messed up time zones References: <501B8C6F.6040100@shopzeus.com> <501BAA84.9010306@shopzeus.com> <501BAE33.4090102@shopzeus.com> <16399.1344003584@sss.pgh.pa.us> <501BED07.5070603@shopzeus.com> <501BFA4F.5010709@pinpointresearch.com> <501C0884.1040106@shopzeus.com> <501C17B1.6020604@pinpointresearch.com> In-Reply-To: <501C17B1.6020604@pinpointresearch.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201208/13 X-Sequence-Number: 47551 > So you took two distinct points in time, threw away some critical > information, and are surprised why they are now equal? Well, I did not want to throw away any information. The actual representation could be something like: "2012-11-04 01:30:00-08 in Europe/Budapest, Winter time" and "2012-11-04 01:30:00-08 in Europe/Budapest, Summer time". It would be unambiguous, everybody would know the time zone, the UTC offset and the time value, and conversion back to UTC would be unambiguous too. I presumed that the representation is like that. But I was wrong. I have checked other programming languages. As it turns out, nobody wants to change the representation just because there can be an ambiguous hour in every year. Now I think that most systems treat ambiguous time stamps as if they were in standard time. And who am I to go against the main flow? I'm sorry, I admit that the problem was in my head.