"Eric S. Raymond" <address@hidden> writes:Hal Murray <address@hidden>:It does this: Look a half-era ahead. If that's still less than a reference date, shift the time stamp forward N cycles for the minimum N that will take it past the reference date.I'm not certain what the reference date is, because the context doesn't exactly match anything in our code. If it were me writing the code it would be the build date of the instance.I don't understand the 1/2 part. If you have the build date, why throw away 1/2 the range?Good question. The main reason I've never tried to fix the wraparound problem myself is tha the moere I look at code like this and Perly's black magic, the less sure I am that I understand anything.One issue is how you are really sure that the clock was right when built. That's another reason to use a fixed date that is surely in the past, but I think the notion of reproducible builds (by which I refer to the notion that the bits built are *exactly* the same on multiple systems) precludes using build time. One of the main things to get rid of when making builds reproducible is any kind of timestamp from the build environment.
Might I suggest that we just have a 'GPSD epoch' in gpsd.h along the lines of:
#define GPSD_EPOCH 1559347200L // not before 1st June 2019
as a time_t value, then however dates and mangled or unrolled the answer should always be post-epoch.
If working in time_t directly you can use the epoch, if working in days/months/years split the epoch into parts with gmtime().
Every major release of GPSD has an epoch that does not change during patches, minor updates, OS releases, compiling by package distributors and hence we have consistency.
GPSD need only change the epoch once every 6-12 months for the next major release, if at all.
If you don't want to do it this way, then an alternative that achieves the same sort of thing would be to define a 'gps min week number, working in un-rolled (or extended) weeks.
#define GPSD_MIN_WEEK 2058
then you can unpack dates, unroll years, etc. and check that the GPS week number you think you have is greater than GPS_MIN_WEEK.
Come to think of it, if you also have the constants:
#define SECONDS_SINCE_1970 315964800L
#define SECONDS_PER_WEEK 604800L
then you can compute GPS min week number from the epoch (above) anyway:
min_week = (GPSD_EPOCH - SECONDS_SINCE_1970) / SECONDS_PER_WEEK;
give or take a few leapseconds.
Mike
Michael J Tubby B.Sc. (Hons) MIET
/ Technical Director
Email: address@hidden
Direct: +44 (0)1905 752892
Mobile: +44 (0)7973 225144
Thorcom Systems Limited
Phone: +44 (0)1905 756 700
Address: Unit 4, 96B Blackpole Trading Estate West,
Worcester, WR3 8TJ, England, UK
Company registered in England & Wales No. 02704696 /
VAT Number GB487925681 / EORI GB487925681000
This email and any attachments to it may be confidential
and are intended solely for the use of the individual to whom
it is addressed.
Any views or opinions expressed are solely those of the author
and do not necessarily represent those of Thorcom Systems
Limited.
If you are not the intended recipient of this email, you must
not take any action based upon its contents or disclose it to
any third-party.
Please contact the sender if you believe you have received
this email in error.