Is keeping original timestamp useful in bazaar commit/pull/etc.?

When using bzr pull, the timestamp of files becomes "now" (option 1), as opposed to keeping the original timestamp in the repo (option 2).

Cons of option 1:

Files which should be the same become different (even if only in the modification time). These differences may "propagate" across pulls/commits/etc. and they would contaminate the record of actual modification times of files in a package.
Build systems (like make), which use the modification time of some files (prerequisites) to evaluate the need for making other files (targets), may not work properly. A case where a file with an "old" timestamp is pulled and the build system ignores that for a correct build while it shouldn't, probably indicates an ill-configured build procedure, or the need for make clean prior to make (and this should be the responsibility of the user). I do not see any case where altering a source file (even if only its timestamp) to avoid the need for make clean is convenient.

Would it be any useful that the timestamp is that of the file in the repository? (option 2; a similar question goes for bzr commit)

In principle, I would say YES, but there should be a good reason for bazaar to work as it does (I only do not see it).

EDIT: The accepted answer alludes exactly to point 2 here (I have posted a thorough answer as well). I had previously seen this as a symptom of an ill-configured build system. But now I see there is no way of configuring a build system for the way I think it should work, with current tools. Using the original timestamp, one would be forced to make clean with every pull, thus rebuilding all targets. Using "now" as the timestamp at least lets the system rebuild only the targets depending on changed prerequisites. But I still see this as the "least damaging" option, while the true objective should be having it both ways: 1) rebuilding only the targets depending on changed prerequisites, 2) keeping the true modification time of files contents across copies.

Solution

Bazaar isn't alone in behaving like this; all version control systems work like this as far as I know.

Using the current time is correct here, because the build system is not aware of version control history - it's just aware of the directory times. In the context of the working tree, that file is actually new.

Imagine the situation where there is a build target that depends on a source file B that is checked into Bazaar with a timeline like this:

T0: User X checks out A and B after at revision 1.
T1: User Y makes a change to B in Bazaar
T2: User X builds a build target that is derived from B (e.g. compiling it)
T3: User X pulls in the new revision made by user Y, the timestamp of B changes to T1 (so earlier than the T2 of the build target)
T4: User X attempts to build again, but the timestamp for B is older than the build artifact and thus nothing is rebuilt