Thanks! Yes, I could go unsigned on the time stamp (and, my increment on the 1 Hz interrupt will do that!). The trick is getting time.c to either treat it as unsigned or to use a 64 bit time_t. I'm using time.h from Microchip. I do not see source code for time.c. Is there a publicly available version of time.c that either makes the time stamp unsigned or makes it 64 bit? Also, what does NTP do after 2038? THANKS! Harold > You could buy yourself another 68 years by just treating it as an unsigne= d > 32 bit value, assuming that you don't care about dates before 1January > 1970. Otherwise, you'll need to adopt the 64 bit "version" of the time_t > data type. > > On Wed, Feb 27, 2019, 10:34 Harold Hallikainen wrote: > >> Thanks for the comments! The IETF RFC below is interesting. I currently >> log stuff with a 32 bit Unix time stamp and convert it to a string >> representing the date and time in the appropriate time zone when >> displaying. The 32 bit counter is updated by a 1 Hz interrupt and now >> and >> then set using NTP. When NTP adjusts by more than one second, the period >> register is adjusted one click in the appropriate direction to speed up >> or >> slow down the interrupt rate. >> >> The 1 Hz interrupt just increments a counter, which is very simple and >> speedy in the interrupt. Using the below RFC method, I'd have to figure >> out year, month, day, hour, minute, second, etc. during the interrupt. >> It >> seems much easier to do this at display time. >> >> The simplest thing seems to be to increase the 32 bit time stamp to 64 >> bits. That would resolve the issue for a LONG time. Making my interrupt >> do >> that is, of course, easy. But, I need time.c to accept the 64 bit time >> stamp and figure out the year, month, date, hour, minute, second. Also, >> NTP would need to return the 64 bit time stamp. At this point, I'm not >> sure what an NTP server returns after 2038 (probably otta look into >> that). >> >> THANKS! >> >> Harold >> >> > Hi Harold, you could try RFC2550: >> > https://tools.ietf.org/html/rfc2550 >> > >> > Regards, >> > Ryan >> > >> > >> > On Wed, 27 Feb 2019 at 16:13, Harold Hallikainen >> > >> > wrote: >> > >> >> I had to deal with Y2k in my firmware way back. I suspect some of my >> >> stuff >> >> will still be running in 2038 when the 32 bit Unix timestamp rolls >> over. >> >> Is there a 64 bit version of time.c? Or what is the best way to deal >> >> with >> >> this? >> >> >> >> Thanks! >> >> >> >> Harold >> >> >> >> >> >> -- >> >> FCC Rules Updated Daily at http://www.hallikainen.com >> >> Not sent from an iPhone. >> >> -- >> >> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive >> >> View/change your membership options at >> >> http://mailman.mit.edu/mailman/listinfo/piclist >> >> >> > -- >> > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive >> > View/change your membership options at >> > http://mailman.mit.edu/mailman/listinfo/piclist >> > >> >> >> -- >> FCC Rules Updated Daily at http://www.hallikainen.com >> Not sent from an iPhone. >> -- >> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist >> > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > --=20 FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .