Hi Tom, Thank you for comment. >> At current implementation, PGTYPEStimestamp_from_asc returns -1. > It looks to me like it returns 0 ("noresult"). Where are you seeing -1?
I took a mistake. Sorry. PGTYPEStimestamp_from_asc returns 0(noresult). PGTYPEStimestamp_fmt_asc given 'noresult' returns -1. > But how come we haven't noticed that > before? Have you added a setlocale() call somewhere? I didn't notice to this point. I added setlocale() to ECPG in my local branch. I will test again after removing it. It looks to me like existing ECPG code does not include setlocale(). So Please ignore about behavior of PGTYPEStimestamp_fmt_asc(). I want to continue to discuss about PGTYPEStimestamp_from_asc. Current PGTYPEStimestamp_from_asc() returns 0, but should we return -1? The document claims about return that "It is set to 1899-12-31 23:59:59.". I wonder. It is the incompatibility, but it may be allowed. because I think usual users may check with errno. Of course, the reason is weak. Some users may check with 0(noresult) from their experience. > That documentation has more problems too: it claims that "endptr" > is unimplemented, which looks like a lie to me: the code is there > to do it, and there are several callers that depend on it. I think so too. The followings have the same problem. PGTYPESdate_from_asc (ParseDate) PGTYPESinterval_from_asc (ParseDate) PGTYPEStimestamp_from_asc (ParseDate) PGTYPESnumeric_from_asc > which is consistent with that, but not very much like what the > comment is expecting. I'm a bit inclined to just drop "block 3". > If we want to keep some kind of test of the error behavior, > it doesn't belong right there, and it should be showing what errno > gets set to. It is easy to exchange block3 to errno-checking. However if we just fix there, it is weird because there is no other errno-checking in dt_tests. > I'm a bit inclined to just drop "block 3". Are you concerned at the above point? Best Regards Ryo Matsumura