Re: timestamps and dates
От | Nigel J. Andrews |
---|---|
Тема | Re: timestamps and dates |
Дата | |
Msg-id | Pine.LNX.4.21.0304281658500.2388-100000@ponder.fairway2k.co.uk обсуждение исходный текст |
Ответ на | timestamps and dates ("Nigel J. Andrews" <nandrews@investsystems.co.uk>) |
Ответы |
Re: timestamps and dates
|
Список | pgsql-general |
On Mon, 28 Apr 2003, Nigel J. Andrews wrote: > > > I'm sure this has cropped up before but I can't find the messages so sorry to > bother everyone... > > I have two systems (both linux) one, let's call it A, running 7.3.1 and one, B, > 7.3.2, although I think that difference is irrelevent as I show below. > > Trying: > > SELECT '2003 Jul 08'::timestamptz > > on A gives me the expected: > > '2003-07-08 00:00:00+01' > > while on B I get: > > '2003-07-07 23:59:00+01' > > (time zone being set for the UK) To follow up my own posting: On B I have now explicitly set the timezone to BST and the above works as expected. In the environment I have been starting my connections from, including the web server, doesn't contain TZ but then neither does the 'A' installation. This makes it seem like the problem is OS installation on 'B'. Indeed, I didn't have a /etc/timezone file on there. Although, I have just added it and it makes no difference. This is must be a problem with my Linux knowledge since I've no idea how `date` was aware of the timezone without either TZ or /etc/timezone. Both systems are not setting timezone in postgres.conf however, system A is a debian 2.2 while system B is immunix (based on Redhat 7.0). In answer to Tom's question in reply about B using leap second accounting, I don't know. Someone here probably can say without thinking whether RH 7.0 did or not. Anyway, I am now happy I can generate a work around easily even if I don't understand why it's necessary. I would of course prefer to understand why. Thanks for the quick reply as usual Tom, -- Nigel Andrews
В списке pgsql-general по дате отправления: