This is how I would solve your problem in perl.

#!/usr/bin/perl

# don't leave home without these two
use strict;
use warnings;

# get time the perl-way (use gmtime instead of localtime for UTC)
# http://perldoc.perl.org/functions/localtime.html
# (the brackets around time are optional)
my @fields = localtime(time);

# extract the relevant values
# the 'dumb' way - single scalars
#my $day   = $fields[3];
#my $month = $fields[4];
#my $year  = $fields[5];
# the smart way - array slice
my ($day, $month, $year) = @fields[3,4,5];

# add required offsets
$month++;
$year += 1900;

# use format codes to zero-pad the month and day values (and also the
# year - just to be sure; replace 'tar' and 'gz' with '%s'-format code
# and a variable if you need them to be dynamic)
my $dbfile  = sprintf 'bugs_db_%04i-%02i-%02i.gz',      $year, $month,
+ $day;
my $webfile = sprintf 'bugzilla_%04i-%02i-%02i.tar.gz', $year, $month,
+ $day;

print "Database file: $dbfile\n";
print "Archive:       $webfile\n";

exit;
[download]

Output:

Database file: bugs_db_2015-07-02.gz
Archive:       bugzilla_2015-07-02.tar.gz

Why not use `date`?

There are 3 reasons - two have been mentioned already.

a) date may not be available - this may or may not concern you at all

b) it's really tricky to handle all side effects of calling external commands (e.g. properly catch the exit code, parse or hide StdErr, actually execute the correct command, ...)

not mentioned yet

c) The returned output of the external command may change unexpectedly. In your case it's not relevant, but you should keep that in mind when handling actual date values, parsing ifconfig output or any other command providing output that is influenced by the current language settings.

In order to properly execute an external command, you should provide a sane environment, evaluate the return code, catch StdOut, catch StdErr and maybe do some other stuff I forgot ... usually I try to find a way to do this stuff in pure-perl because it's easier to get it right. ;)