On 11/28/2017 4:01 AM, Maciej Sumiński wrote: > On 11/28/2017 09:02 AM, jp charras wrote: >> Le 28/11/2017 à 00:27, Tomasz Wlostowski a écrit : >>> On 27/11/17 21:18, Wayne Stambaugh wrote: >>>> On 11/27/2017 2:56 PM, jp charras wrote: >>>>> Le 27/11/2017 à 20:18, Tomasz Wlostowski a écrit : >>>>>> On 27/11/17 17:05, Henner Zeller wrote: >>>>>>> Yes, I know about the time_t being different type situation, >>>>>> >>>>>> Why not just use uint64_t instead of time_t? It's identical on every >>>>>> platform. >>>>>> >>>>>> Tom >>>>>> >>>>> >>>>> Looks good to me. >>>>> >>>>> >>>> >>>> Will this cause issues on platforms where time_t is 32 bits? >>>> >>> These platforms have a serious issue anyway if they'll live long enough >>> to reach year 2038 ;-) >>> >>> IIRC the timestamp is just an unique ID of the item in Kicad, right? >>> It's never propagated to the system time, so 64-bits IMHO 64-bits should >>> be safe everywhere. >>> >>> Tom >> >> Yes it is a unique ID only. >> It is converted to a date in footprint editor (legacy mode) to show the last >> edition date to the user. >> This is easy to convert a uint64_t to show this message. > > I suppose the most elegant solution would be to change time_t in KiCad > source code to uint64_t. This leaves no ambiguity and should be easy to > handle with swig. Time stamps are only saved and loaded as 32 bit values so I'm not sure unint64_t makes sense.
> > Regards, > Orson _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
