Sorry Clemens,

but you have missed the point, the point being that the year component of the date string returned by strftime for -ve (or BCE) years are truncated to the -ve sign + the first three digits of the year. This is not the case for the result returned by date or datetime, which return the -ve sign + the full four digits of the year.

All equivalent functions should return consistent results. I suspect it is a formatting issue in the output of strftime.

As to the reference below, Gregorian calendar dates are only accurate after its introduction in 1582, the proleptic Gregorian calendar projects the Gregorian calendar back from 1582 so that:

Gregorian 0001-01-01 == Julian 0001-01-01

Gregorian dates prior to that point in time are somewhat meaningless except as a reference to elapsed time wrt now.

Future dates are also somewhat meaningless except as a reference to elapsed time wrt now. I suspect the reference to the year 9999 has to do with year format limited to four characters "yyyy", assuming, of coarse, that our descendants are still using the Gregorian calendar then.

The Julian Day Count (not the same Julius as the Julian Calendar) is an integer count of days from a reference point and is accurate up to the unsigned integer limit of the math module used to calculate it.

People who use dates outside stated limits below are usually well aware of the issues involved.

My issue, as stated above, is to do with the inconsistent returns from equivalent functions. This, I think should be corrected.

Regards,
John


On 5/10/2014 19:59, Clemens Ladisch wrote:
John wrote:
-4713-11-25 12:00:00    <-- 4 digit year
-471-11-25 12:00:00     <-- 3 digit year
-001-12-31     <-- 3 digit year
-001-12-31     <-- 3 digit year
-1975-10-21    <-- 4 digit year
-197-10-21     <-- 3 digit year

The documentation <http://www.sqlite.org/lang_datefunc.html> says:
| These functions only work for dates between 0000-01-01 00:00:00 and
| 9999-12-31 23:59:59. For dates outside that range, the results of
| these functions are undefined.


Regards,
Clemens
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to