Handle four-digit year in minmea_gettime

[asund]

• Handle four digit years provided by ZDA in minmea_gettime
• Assume GPS epoch to allow dates prior 2000 to be parsed

[kosma]

This really needs unit testing to make sure we're handling all cases correctly. Could you please add tests for edge conditions in test_minmea_gettime? Specifically, the following cases:

• year=79 (should read as 2079)
• year=80 (should read as 1980)
• year=1979 (?????? - I don't know how we should handle this one, possibly as a wraparound in receiver firmware, so... 2079?)
• year=1980 (should read as 1980)

[asund]

Thank you, will do. Do you mind the assumption of the GPS epoch for interpreting two digit years?

[kosma]

The assumption sounds fair to me - at least, this the most logical way to handle two-digit years. Also, minmea_gettime() is just a convenience helper, so if someone happens to own a receiver with really b0rked date handling they can just roll out their own version.

[asund]

Another question: I've written tests that run well on my Mac, but I'm a little less confident in systems with a 32-bit time_t and a standard library that is affected by the year 2038 problem. I can ifdef out tests out of this range based on sizeof(time_t) and an assumption that a typical platform will use a signed int. Does this sound good to you?

EDIT: Can't mix ifdef and sizeof, so I used an if instead.

[kosma]

I like if (sizeof(time_t) == sizeof(int64_t)) as platforms with 32-bit time_t are screwed anyway. One more thing though: can you please normalize whitespace in your patches? All tabs should be four spaces. That, and we're good to merge.

[asund]

Thanks for your patient feedback.

[kosma]

Merged. Thanks a lot!