Bug 157196

Summary: About LibreOffice information, add the build date-time YYYYMMDDHHMM after the build ID
Product: LibreOffice Reporter: m_a_riosv <miguelangelrv>
Component: LibreOfficeAssignee: Not Assigned <libreoffice-bugs>
Status: NEW ---    
Severity: enhancement CC: lo, stephane.guillou
Priority: low    
Version: 24.2.0.0 alpha0+   
Hardware: All   
OS: All   
Whiteboard:
Crash report or crash signature: Regression By:
Bug Depends on:    
Bug Blocks: 103202    

Description m_a_riosv 2023-09-11 19:43:20 UTC 
About LibreOffice information, add the date-time of the build after the build ID, I think a useful information, to see at a glance.

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: be9d7bee88eff89c0d361f23abb447ac2086c3b4
CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded Jumbo

Build ID: be9d7bee88eff89c0d361f23abb447ac2086c3b4 YYYYMMDDHHMM

BTW, Locale and Calc information, could be in the same line avoiding one line in the information.
Comment 1 Mike Kaganski 2023-09-12 05:36:45 UTC 
(In reply to m.a.riosv from comment #0)
> I think a useful information, to see at a glance.

What does it give to a reader? The date of a build is very likely to be misleading. One build of 7.6.1.2 (say, in DistroA) will definitely have a different YMD compared to a build of 7.6.1.2 in DistroB.
Comment 2 m_a_riosv 2023-09-12 13:17:53 UTC 
(In reply to Mike Kaganski from comment #1)
>................
> What does it give to a reader? The date of a build is very likely to be
> misleading. One build of 7.6.1.2 (say, in DistroA) will definitely have a
> different YMD compared to a build of 7.6.1.2 in DistroB.
So we can't have the date corresponding to the build ID?

And e.g., when we are looking at recent master builds, we can quickly know if it is from yesterday or a week ago.

Can it bother?
Comment 3 Mike Kaganski 2023-09-12 14:01:18 UTC 
(In reply to m.a.riosv from comment #2)
> So we can't have the date corresponding to the build ID?

Ah, so likely you want a timestamp from the *commit* (that hash is used as the build id), right? And likely, the timestamp of its merge.

I'd say, it makes sense, but only for debug builds.
Comment 4 Stéphane Guillou (stragu) 2023-09-25 20:18:20 UTC 
Thanks m.a.riosv.

In a way, "Build ID" is misleading. Maybe a better name would be "Last commit"?

I kind of agree with Mike, would be most useful for debug and daily builds, where we have dozens of builds for a single version number. YYYY-MM-DD is probably sufficient.

I would be happy to have that information at a glance when doing QA work on Bugzilla, but given that the information is one hyperlink away, I think the priority is "low".