6 Commits (f901bb50e33ad95593bb68f7b3b55eb2e47607dc)

Author	SHA1	Message	Date
Tom Lane	f901bb50e3	Add make_date() and make_time() functions. ... Pavel Stehule, reviewed by Jeevan Chalke and Atri Sharma	12 years ago
Tom Lane	a303e4dc43	Extend the date type to support infinity and -infinity, analogously to ... the timestamp types. Turns out this doesn't even reduce the available range of dates, since the restriction to dates that work for Julian-date arithmetic is much tighter than the int32 range anyway. Per a longstanding TODO item.	17 years ago
Bruce Momjian	46be0c18f1	> After all that about numbering centuries and millenia correctly, ... > why does CVS tip still give me > > regression=# select extract(century from now()); > date_part > ----------- > 20 > (1 row) > [ ... looks in code ... ] > > Apparently it's because you fixed only timestamp_part, and not > timestamptz_part. I'm not too sure about what timestamp_trunc or > timestamptz_trunc should do, but they may be wrong as well. Sigh... as usual, what is not tested does not work:-( > Could we have a more complete patch? Please find a submission attached. I hope it really fixes all decade, century and millenium issues for extract and *_trunc functions on interval and other timestamp types. If someone could check that the results are reasonnable, it would be great. I indeed overlooked the fact that there were two functions. The patch fixes the code so that both variants agree. I added comments to interval extractions, because it relies on the C division to have a negative remainder: -7/10 = 0 and remains -7. As for *_trunc functions, I have chosen to put the first year of the century or millennium: -100, 1, 101... 1001 2001 etc. Indeed, I don't think it would make sense to put 2000 (last year of the 2nd millennium) for rounding all years of the third millenium. I also fixed the code so that all decades last 10 years and decade 199 means the 1990's. I have added some tests that are relevant to deal with tricky cases. The formula may be simplified, but all these cases must pass. Please keep them. Fabien Coelho	22 years ago
Bruce Momjian	1934055cbe	Please find a small patch to fix the brain damage "century" and ... "millennium" date part implementation in postgresql, both in the code and the documentation, so that it conforms to the official definition. If you do not agree with the official definition, please send your complaint to "pope@vatican.org". I'm not responsible for them;-) With the previous version, the centuries and millenniums had a wrong number and started the wrong year. Moreover century number 0, which does not exist in reality, lasted 200 years. Also, millennium number 0 lasted 2000 years. If you want postgresql to have it's own definition of "century" and "millennium" that does not conform to the one of the society, just give them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-) IMO, if someone may use the options, it means that postgresql is used for historical data, so it make sense to have an historical definition. Also, I just want to divide the year by 100 or 1000, I can do that quite easily. BACKWARD INCOMPATIBLE CHANGE Fabien Coelho - coelho@cri.ensmp.fr	22 years ago
Tom Lane	1a908a00b0	Fix datetime input parsing to accept YYYY-MONTHNAME-DD and related syntaxes, ... which had been unintentionally broken by recent changes to tighten up the DateStyle rules for all-numeric date input. Add documentation and regression tests for this, too.	22 years ago
Thomas G. Lockhart	0d93504c40	Add regression tests for date, time, and time with time zone types. ... Modify date->timestamp conversion to use mktime(). This should do better than before around Daylight Savings Time transitions.	26 years ago