bug in gmtime_r and friends.

bug in gmtime_r and friends.

[alf salte]

I saw this error in newlib version 3.2 for cygwin but I guess it is still there in newer versions as well.
Reading the sourcecode for gmtime_r I found that
#define EPOCH_ADJUSTMENT_DAYS   719468L
This is meant to move the epoch from 1.1.1970 (unix time start) to 1.3.0 (yes, year 0 - same as 1 BC).
The problem is that the adjustment is wrong. In computing the number of days from 1.1.0 to 1.1.1970 to get a value such as 718527 the year 0 is counted as a leap year as it should be in proleptic Gregorian calendar. but when subtracting days for January and February they subtract 31 and 28 ignoring that year 0 is a leap year in Gregorian calendar, thus arriving at 719468 instead of 719467 as it should be. February has 29 days in year 0 in Gregorian calendar, not 28. So this adjustment is off by one day.
Computing 1970 * 365 + (1970/4) - (1970/100) + (1970/400) - 31 - 29 gives 719467 not 719468.The epoch as specified (719468) starts at 29.2.0 or 29th February year 0 - not March 1st year 0 as the comments indicate it should.
Please fix.
I assume the code otherwise give correct results due to other errors which also then have to be fixed down the line because people fixed the wrong place. The problem is this epoch adjustment.
It is possible you want to keep this epoch adjustment as it is 0th of March year 0 but if so the comment should be changed to reflect that.
It is also a good idea to explain why it is 29 and not 28 days in February that year - simply state it is a leap year since year 0 is leap year in Gregorian calendar.
Note that historically it was Julian calendar in use at the time and nether year 4 nor year 0 was leap years due to Augustus' decree which canceled all leap years from 8 BC to at least including 4 AD. Year 8 probably was leap year. This means that the date 1.3.0 in Gregorian calendar was a completely different date historically - it is somewhat tricky to convert to find the correct historical date since Gregorian and Julian calendar is not in synch at this point (Julian calendar is slightly ahead of Gregorian calendar at this point in time). By computing you find that proleptic Julian calendar 3.3.0 is same date as Gregorian calendar 1.3.0 and it is the same as historical caelndar 4.3.0 so Wednesday, March 4th year 753 AUC is the date that Gregorian calendar count as 1st of March 1 BC. In Roman counting March 4th would be "Wednesday, 4 days before Nones of March 753 AUC".

Re: bug in gmtime_r and friends.

[Brian Inglis]

On 2022-02-09 09:24, alf salte via Newlib wrote:
> I saw this error in newlib version 3.2 for cygwin but I guess it is still there in newer versions as well.
> Reading the sourcecode for gmtime_r I found that
> #define EPOCH_ADJUSTMENT_DAYS   719468L
> This is meant to move the epoch from 1.1.1970 (unix time start) to 1.3.0 (yes, year 0 - same as 1 BC).
> The problem is that the adjustment is wrong. In computing the number of days from 1.1.0 to 1.1.1970 to get a value such as 718527 the year 0 is counted as a leap year as it should be in proleptic Gregorian calendar. but when subtracting days for January and February they subtract 31 and 28 ignoring that year 0 is a leap year in Gregorian calendar, thus arriving at 719468 instead of 719467 as it should be. February has 29 days in year 0 in Gregorian calendar, not 28. So this adjustment is off by one day.
> Computing 1970 * 365 + (1970/4) - (1970/100) + (1970/400) - 31 - 29 gives 719467 not 719468.The epoch as specified (719468) starts at 29.2.0 or 29th February year 0 - not March 1st year 0 as the comments indicate it should.
> Please fix.
> I assume the code otherwise give correct results due to other errors which also then have to be fixed down the line because people fixed the wrong place. The problem is this epoch adjustment.
> It is possible you want to keep this epoch adjustment as it is 0th of March year 0 but if so the comment should be changed to reflect that.
> It is also a good idea to explain why it is 29 and not 28 days in February that year - simply state it is a leap year since year 0 is leap year in Gregorian calendar.
> Note that historically it was Julian calendar in use at the time and nether year 4 nor year 0 was leap years due to Augustus' decree which canceled all leap years from 8 BC to at least including 4 AD. Year 8 probably was leap year. This means that the date 1.3.0 in Gregorian calendar was a completely different date historically - it is somewhat tricky to convert to find the correct historical date since Gregorian and Julian calendar is not in synch at this point (Julian calendar is slightly ahead of Gregorian calendar at this point in time). By computing you find that proleptic Julian calendar 3.3.0 is same date as Gregorian calendar 1.3.0 and it is the same as historical caelndar 4.3.0 so Wednesday, March 4th year 753 AUC is the date that Gregorian calendar count as 1st of March 1 BC. In Roman counting March 4th would be "Wednesday, 4 days before Nones of March 753 AUC".

The calculation basis is used for compatibility with the standard time 
in C++; see the explanation in:

https://howardhinnant.github.io/date_algorithms.html#days_from_civil

where the date calculations are done by offsetting epoch to some 
multiple of a 400 year Gregorian era - so your concern is handled - 5 
eras from 2000 to 0000 - minus the delta from 1970 to 2000 - minus the 
delta from 0000 to 0000.03.01 - plus or minus a tweak to ensure the time 
delta result is < 86400s.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]