Problem description: Mozilla's build ID as displayed in the titlebar encodes date and hour in the local timezone. With development going on all over the world, I've seen some confusion in bug discussions regarding build IDs of local CVS-based builds, which may differ from the "official" ones at mozilla.org. RFE: Change .../mozilla/config/mozBDate.pm so that the build ID does not refer to the local timezone, but a fixed one, say UTC (or US Pacific if folks at Netscape prefer), thus making build IDs of all CVS builds comparable. This would be my patch to change it to UTC: --- mozBDate.pm.orig Mon Mar 5 11:29:43 2001 +++ mozBDate.pm Mon Mar 5 11:29:55 2001 @@ -49,7 +49,7 @@ # XP way of doing the build date. # 1998091509 = 1998, September, 15th, 9am local time zone - my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime; + my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = gmtime(time); # localtime returns year minus 1900 $year = $year + 1900;

Switching to UTC sounds good to me. Granrose, Leaf: are there any other scripts that would need to change to handle the time switch?

offhand, no idea. I'm not convinced that there is that much confusion in bugs since most people who are doing their own builds are probably not setting BUILD_OFFICIAL so their buildid should be 00000000. But I'm ok with switching to UTC as long as we announce it to the world with plenty of lead time so people don't start freaking out (which they will anyway) when we change it.

i *believe* that all the scripts will continue to build and generate correct build ids. Nice of perl to have gmtime be broken the same way localtime is =) AFAIK, all platforms use the buildid in config to generate the buildid for talkback as well, so we should be safe on all fronts. The only trouble is that users in the centre of the world (the pacific timezone) are going to be confused as hell when the delivery directories appear several eight hours in the past. But we live to confuse hapless users!

My point is merely to have a unique build ID. Whether or not that's then based on UTC does not concern me much. (Although I think UTC would serve well here as its an accepted standard). Right now I have to write: hm, I did a CVS build at 9:30 a.m. GMT+1, that's, uh, in US Pacific, wait a minute ... I would like to write: I have build ID 2001030609. And that would be unique so everyone knows what I'm talking about. If you are really concerned about confusion in the user base, stick with US Pacific. [BTW, in contrast to popular belief, the US west coast is *not* the centre of the world ... ;-) ]

I agree, jag just wondered how someone posted details about a bug with a build id a few hours in the future, and it seems it could be because it was an rpm build. Changing the build id to be UTC/GMT gives us benefits without incurring losses. Since there's a patch, can we get some test builds done so we're sure the build system won't fall over, and get it into the main system (tip) for 0.9.1 please?

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

*** Bug 152052 has been marked as a duplicate of this bug. ***

It should be the same time CVS uses for checkouts, which is GMT, I believe.

Changing target milestone to 'Future' since 'mozilla1.0.1' came and went already.

Mass reassign to default build config owner

Mass reassign of Build/Config bugs to Leaf.

Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.

How we do build IDs are in flux anyway (bug 383167 deletes most of the build date scripts this bug refers to, for instance), so WONTFIXing this.