Re: [BUGS] Bug #630: date/time storage problem: timestamp parsed

2002-04-09 Thread Michael Loftis

On FreeBSD newsyslog shows the same interesting sort of problem witha 
'time' value of @T02 on the day of the leap change, sudden;y it'll balk 
saying the format of the line is wrong.  Could be related on an outside 
area as newsyslog uses mktime and some ISO time format.

Sean Chittenden wrote:

>Err... brain-o on my part (didn't know what I was looking for until I
>put in a date that does exist and followed it through):
>
>>(gdb) b DecodeDateTime
>>Breakpoint 1 at 0x811568d: file datetime.c, line 892.
>>(gdb) b DetermineLocalTimeZone
>>Breakpoint 2 at 0x81161a9: file datetime.c, line 1463.
>>(gdb) run foo
>>
>>backend> create table tt ( tt timestamp );
>>backend> insert into tt values ('2002-4-7 2:0:0.0');
>>
>
>If I use 3am on the 7th, I get the following:
>
>(gdb) print *tm
>$2 = {tm_sec = 0, tm_min = 0, tm_hour = 3, tm_mday = 7, tm_mon = 3,
> tm_year = 102, tm_wday = 0, tm_yday = 96, tm_isdst = 1,
> tm_gmtoff = -25200, tm_zone = 0x28420c78 "PDT"}
>
>Looks like it's a "bug" in mktime() on FreeBSD: it doesn't seem to do
>so well with invalid times that happen between daylight savings
>time...  or is that a postgres thing for not kicking up an error (out
>of bounds time)?  Or should 2am PST be converted to 3am?  -sc
>



---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [BUGS] Bug #630: date/time storage problem: timestamp parsed

2002-04-15 Thread Michael Loftis

Cuttign down the CC: list this time, apologies if I cut too much and 
someone misses a copy of this

Sean Chittenden wrote:

>
>The FreeBSD folk are absolutely adamant about having mktime() no
>compensate for deadzones between DST shifts and they insist that the
>application handle this.  Someone's off looking at how other OS'es
>handle this, but this could be an arduous battle on that front.  <:~)
>
Personally I'd like to see FreeBSD do away with this strange behaviour. 
 It cause my grief because certaint hings *MUST* be done at 0200 every 
day in our system, I was forced to do them manually recently, shifing 
several hours of work into daytime which had to be paused and bulked 
into the next days work.  I realise that this is getting off track but 
it just points out that the FreeBSD behaviour is IMHO WRONG.  It causes 
applications to fail in an unexpected and odd way.

I'm not objecting to pg patching for it (no choice at the moment) but I 
hope the pg team 'officially' puts a little pressure on the BSD folk to 
make this behave as expected.

I don't have any compliance docs at the moment, but this strikes me as 
somewhat out of spec personally.

>>I know the attached patch is something of a hack, but it works.  I'm
>>not totally wild about altering the original time object, but I
>>don't know that I have a choice in this case.  Does anyone switch
>>timezones and only adjust their clocks by anything other than 60min?
>>I seem to recall that happening in a few places, but the patch isn't
>>any worse than where we are now. ::shrug:: This look like an okay
>>patch?
>>
>
>Are there any objections to the following?  Instead of returning 0 or
>utc, I could have it raise an error.  Would that be acceptable?  -sc
>



---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [BUGS] Bug #630: date/time storage problem: timestamp parsed

2002-04-15 Thread Michael Loftis



Sean Chittenden wrote:

>>>The FreeBSD folk are absolutely adamant about having mktime() no
>>>compensate for deadzones between DST shifts and they insist that
>>>the application handle this.  Someone's off looking at how other
>>>OS'es handle this, but this could be an arduous battle on that
>>>front.  <:~)
>>>
>>Personally I'd like to see FreeBSD do away with this strange
>>behaviour.  It cause my grief because certaint hings *MUST* be done
>>at 0200 every day in our system, I was forced to do them manually
>>recently, shifing several hours of work into daytime which had to be
>>paused and bulked into the next days work.  I realise that this is
>>getting off track but it just points out that the FreeBSD behaviour
>>is IMHO WRONG.  It causes applications to fail in an unexpected and
>>odd way.
>>
>>I'm not objecting to pg patching for it (no choice at the moment)
>>but I hope the pg team 'officially' puts a little pressure on the
>>BSD folk to make this behave as expected.
>>
>
>Feel free to read over their arguments (archive may not be 100% up to
>date):
>
>http://docs.freebsd.org/mail/archive/2002/freebsd-standards/20020414.freebsd-standards.html
>
>>I don't have any compliance docs at the moment, but this strikes me
>>as somewhat out of spec personally.
>>
>
>::shrug:: I've gotten enough push back to have an indifferent opinion:
>I just want to see PG work w/ some of the bogus data I get every now
>and then.  :~)  -sc
>
Yes but not everyone changes over at 2AM on the specific day.  The rest 
of the world for the most part doesn't in fact.  I don't know what 
mktime() behaviour is in different locales (IE different TZs) but if its 
the same (IE deadzone @ the same time when the TZ is something in say 
the EU who follow different rules) then its broken.  I've got a FreeBSD 
4.3 box here I do most of my serving on I'll see if I can get a little 
time to do some testing with different TZs.  I don't think that the way 
BSD handles it is correct

Also browsing the discussion archives it seems that mktime() atleast on 
BSD is inconsistent with how it handles bogus dates anyway.  Looks like 
the BSD guys are going to be doing a little navel-looking over this.



---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [BUGS] PostgreSql Installation

2002-04-21 Thread Michael Loftis

Firstly pgsql-bugs is not the appropriate place for this.  pgsql-general 
would have been.

Secondly, I regret to inform you, that there is no official port of 
PostgreSQL to Windows 2000.  People have reported successfully compiling 
it using cygwin, please search the harchives at 
http://archives.postgresql.org/ first, if you don't find oyur answers 
there then post a question to [EMAIL PROTECTED], not pgsql-bugs.

Thank you

Michael Loftis

[EMAIL PROTECTED] wrote:

> Sir,
> recently I have downloaded the postgreSql  and I want to install it in 
> windows 2000
> operating system. can you suggest me please what to do or where I can 
> look for this. thank you.
>
> Rahman




---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html