Looks like a classic "off-by-one" error. You should make sure that you are storing all date stamps in the UTC format.
Read the section on "Converting to and from UTC" here:
https://www.drupal.org/node/291799
If the date/time field is storing the German time (UTC+1h) then it will end up adding another +1h when it localizes the time, and you'll end up one hour ahead.
"There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors."
UPDATE: As you say in your comment below, you can get the desired result by simply subtracting 1h from each datestamp in order to convert from Berlin time to UTC.
However, this approach will only work if you are certain that the time field in the import file will always contain UTC+1 times.
If you ever need to import files that could be in different time zones, you'll need to follow the API.
To convert a local date back to UTC to store it in the database, do:
$date = // local date value
$local_zone = // the name of the local timezone, e.g., 'Europe/Berlin'
$type = // the type of date value, DATE_DATETIME, DATE_ISO, or DATE_UNIX
$date = date_make_date($date, $local_zone, $type);
date_timezone_set($date, timezone_open('UTC'));
// $date now contains the UTC value of the date.
// Output it like:
print date_format_date($date, 'custom', 'm/d/Y H:i');
In order to generalize your database import, you would also need to include a field for the $local_zone
for each timestamp.
It sounds like you will always be importing Berlin timestamps, but I just wanted to make sure that you understood the drawbacks to simply subtracting 1h from each timestamp rather than following the API.
Even if simply subtracting 1h works for you in this case, there is value to doing this the right way, in case you ever need to import a file from another timezone, or one with mixed timezones -- either in your current project, or a future one.