Opened 5 years ago

Last modified 14 months ago

#11506 new defect

Users are confused by the 2000-01-01 00:00 UTC timestamp

Reported by: lunar Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-helpdesk-frequent, TorBrowserTeam201601, GeorgKoppen201601, tbb-rbm
Cc: gk, boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Picture yourself: your browser tells you that there is an update. You go get the new shiny thing. And then, when you look at the date on it, it says more than 14 years ago. Confusing, neh?

I guess using the date of the latest Git commit would just work great.

Child Tickets

Change History (13)

comment:1 Changed 5 years ago by gk

Cc: gk added

comment:2 Changed 4 years ago by erinn

Keywords: needs-triage added

comment:3 Changed 4 years ago by gk

Component: Tor bundles/installationTor Browser
Keywords: tbb-gitian added; needs-triage removed
Owner: changed from erinn to tbb-team

comment:4 Changed 3 years ago by gk

Keywords: TorBrowserTeam201601 GeorgKoppen201601 added
Severity: Normal

This got fixed upstream it seems: https://github.com/devrandom/gitian-builder/commit/bb4f92f6cbde6ee78e39ae35b0934da3b55e154d. Might be just a matter of cherry-picking the respective commit.

comment:5 in reply to:  4 Changed 3 years ago by gk

Replying to gk:

This got fixed upstream it seems: https://github.com/devrandom/gitian-builder/commit/bb4f92f6cbde6ee78e39ae35b0934da3b55e154d. Might be just a matter of cherry-picking the respective commit.

Hrm. This is using the last remote specified in the descriptor, a thing we probably don't want. Nothing for 5.5 then, which is sad.

comment:6 Changed 2 years ago by gk

Cc: boklm added

Might be time to figure out a solution for this one (see #19400 and https://bugzilla.mozilla.org/show_bug.cgi?id=1153978).

comment:7 Changed 2 years ago by boklm

I think there are different solutions:

  • we can use the time of the commit from tor-browser-bundle.git. The drawback is that we can't do partial rebuilds anymore, as any commit will change the timestamp used everywhere
  • we can use the time of the last commit on the gitian descriptor file. However, the descriptor files are not always changed between two releases
  • we can use the time of the last commit from one of the remotes specified in the descriptor (tor-browser.git for the firefox descriptor)
  • we can manually set a value for REFERENCE_DATETIME in gitian/versions and update it while preparing a new release

comment:8 Changed 2 years ago by gk

Partial rebuilds are worth to have. But I actually don't see how any of the four possible solutions you brought up solves this bug while keeping this option. I mean, even if we set REFERENCE_DATETIME in gitian/versions the timestamps would be different (e.g. those embedded in binaries that don't get rebuilt).

comment:9 Changed 2 years ago by boklm

If we set REFERENCE_DATETIME in gitian/versions, we can update its value when preparing a new release, but keep the same value for all the intermediate builds we do for one release. This does not allow partial rebuilds between two releases, but allows it for intermediate builds for one release.

comment:10 Changed 2 years ago by gk

I had some ideas here this morning. First, it occurred to me the build id things is orthogonal to the user confusion this ticket is about. I opened #19528 for the former.

Can't we just adapt the timestamps in the bundle step by either using something hard-coded or preferably by e.g. extracting the date from the changelog in the mkbundle* scripts and making that available in the bundle step?

comment:11 Changed 23 months ago by cypherpunks

Using current timestamp of commit or tag or anything has some complicated issues to work out, understandable.
What's wrong with just setting to 2020/1/1 00:00:00? No more issues with OSX saying the current version is newer, and minimal effort needed, or am I missing something?

comment:12 Changed 16 months ago by gk

#22595 is a duplicate. Note, it might confuse tools if the timestamps are set to a fixed date. Thus, we should try to find a solution that is avoiding that.

comment:13 Changed 14 months ago by gk

Keywords: tbb-rbm added; tbb-gitian removed

Moving over to rbm

Note: See TracTickets for help on using tickets.