Formatting timestamps in trice log

[dAxi-flw6]

I have a question regarding formatting timestamps in trice log, the documentation demonstrates only a few cases here and it is not clear to me what the possibilities are.

As 32-bit timestamp, I want to use a date time, which is uint32_t value with seconds from 1st of January 2000. Is there any way to represent such value in trice log as date time string, in format YYYY-MM-DD HH::mm::ss or something like that

If I try to use -ts32 s flag, I get error, it seems to work only on -ts flag, other examples that I found in code mainly use -ts32 "time:%d" or some variation of it

trice log -port "COM10" -baud 2000000 -stopbits "1" -parity "none" -databits 8 -singleFraming -addNL -hs=off -ts off -ts32 s    
COM10:        file.c    41 s%!(EXTRA uint64=12708) Date time update 12708

[rokath]

Using 1 second as 32-bit timestamp unit, is, maybe, unnecessary overhead. The Trices arrive typically within 100ms or less at the host side, so the host timestamps could be ok for what you want and they are already formatted the way you want. And your target does not need to handle timestamps at all then.

It is possible to extend the Trice tool with a -ts YMDHMS option to convert seconds into date and time. But that would have the impact, that your target knows the exact second count since 1970-01-01-00-00-00. I do not think, that this makes some sense.

-ts32 s is an invalid usage. See this trice help -log output snippet:

  -ts string
    	Target timestamp general format string at start of each line, if target timestamps existent (configured). Choose between "µs" (or "us") and "ms", use "" or 'off' or 'none' to suppress existing target timestamps. Sets ts0, ts16, ts32 if these not passed. If several trices form a log line only the timestamp of first trice ist displayed. (default "µs")

Also you write -ts off and -ts32 s at the same time, what makes no sense.

The error you showed, seems to have a different root cause. Please share the line 41 from file.c.

[dAxi-flw6]

I am sorry for late reply, and thank you for your answer

Regarding, the error, I don't have that file on hand now, but I've set the log with the argument -ts32 s and what I see in log:

Jun 12 15:49:21.762855  COM10:           scheduler.c   339 s%!(EXTRA uint64=3293097601) Starting application ver.: RuntimeVerCode

And now, sharing the line 339 from scheduler.c:

TRiceS("Starting application ver.: %s", (char const*)GetVersion());

If I use -ts32 "time: %ds ", then in log I see:

Jun 12 15:53:11.620175  COM10:           scheduler.c   339  3293097601s  Starting application ver.: RuntimeVerCode

[dAxi-flw6]

Now, regarding main question, let me explain the reason for using 32-bit timestamp with 1 second resolution:

What I am trying to do, is to use Trice as lightweight logging framework for use on devices that are battery powered and should last for 10+ years on a single battery. The main purpose is to use trice to log into external flash and if any maintenance or support is needed, then the log is downloaded and parsed.

This is why I don't want to use host side. And my idea was to use 16-bit timestamps if I need to time some short durations and etc., but for reporting errors and warnings, I would like to use 32-bit timestamp with datetime, this is also convenient as device does keep track of UNIX timestamp anyway

So, if I try to use -ts YMDHMS, then in log I see:

Jun 12 16:11:33.532016  COM10:           scheduler.c   339 262:58:54,601 Starting application ver.: RuntimeVerCode

Though the timestamp value at that time is: 946734601

[rokath]

Thanks for the explanation @dAxi-flw6 - this use case I did not have in my mind before.

-ts YMDHMS is an invalid usage and the Trice v1.0 tool silently ignores that and assumes -ts ms then. This is a bug and fixed now in the main branch. The new behaviour is an error message.

What you see with 262:58:54,601 is 262 hours, 58 minutes, 54.601 seconds, but this assumes ms as uptime and not s as unit and is useless.

The values 3293097601 and 946734601 seem also somehow not correct:

ms@Mac Src % date +"%s"       
1749932858
ms@Mac Src % date -r 1749932858
Sa 14 Jun 2025 22:27:38 CEST
ms@Mac Src % 

It is possible to add the option -ts32 epoch to the trice tool to match your use case.

EDIT: If you plan to produce devices valid beyond 2038, we need to handle that correctly.