kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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