THis is how it is supposed to work. CET is really CET. CEST is a different zone. You should *always* use the Africa/Algiers type zones (continent/location).

And it's good behaving for WAT timezone to? 10 states use only WAT and only one is using WAT/WAST. (and PHP is only checking if for timezone is relevant summer time and returned always summertime).

So add description of this behaving into documentation because if you are able define timezone by place (good for handling normal/summer time) is strange to get summer time when you are setting normal time.

May be it's because backward compatibility but it's not described in documentation. Luckily I implemented function at good time (CEST).

Solution will be using UTC+n but it returned error too :-(

Bug is in the documentation (unexpected and undocumented behavior).

Please explain what exactly you think is wrong.
I don't understand a word from your description.
A short reproduce case with expected and actualy values would help a lot.

In documentation you provide continent/location for setting timezone (in documentation $timezone_identifier)

You are able set timezone by timezone code (UTC, WET, CET, etc.).

This timezone is defined like distance form UTC (ie. CET = UTC+1).

It's strange to accept UTC+2 for dates when some places in current timezone has summer time (for CET it's CEST) because some countries don't have summer time (Algeria has CET, but they don't have any CEST). So add this type of intelligence into functions is simply bad. For getting correspondent local time is continent/location and not shifting timezones.(CET != CEST)

May be CET is not the best example. Better is WAT. Only one country use summertime and PHP is automatically returning WAST...

Solution:
- add description of this behaving into documentation (easiest way) or
- handle timezones like UTC+n, so add summertime codes, because now setting CEST fails.

Please let me know if miss something.

UTC+x are there just for you convenience.
If that's NOT what you need, use the correct name of the timezone you need.

Once again.

I have data (time is in CET timezone whole year). So why when I set by date_default_timezone_set() CET, function returned me UTC+2 (ie. CEST) when some palces in CET timeznoe are using CEST. I don't need continent/location definition, because when I set CET it is UTC+1 (please read some further docs about timezones). So returning CET/CEST depending on date is wrong because CET != CEST.

I know how have I do some 'walk around'. But when I have to try some places if they are in the right timeznone (or the right UTC+n) and use summer time or not it's stupid and wrong. And all because some really intelligent people implemented some strange 'intelligence' into PHP time/date functions.

UTC+x are there just for you convenience.
- no, this is because it shows clear relations between different timezones.

Notice: date_default_timezone_set() [function.date-default-timezone-set]: Timezone ID 'UTC+1' is invalid 
Notice: date_default_timezone_set() [function.date-default-timezone-set]: Timezone ID 'GMT+1' is invalid

So how to set default timezone to UTC+1 ???

Result: it is not bug, it is wrong deign, but how to write bug report about wrong design?

There is no wrong design here. Every area has very specific rules about which GMT offset there currently is, and also what it was in the present. This is why we support  500+ different areas like you can see in our documentation:
http://no2.php.net/manual/en/timezones.php
So yes, you *do* need the timezone name, and not CET for example. There are abbreviations that are ambiguous (like EST) so they are *not* safe to use. Please don't lecture us on how this should work.

The CET ones you are mentioned are marked as "do not use" on this documentation page:
http://no2.php.net/manual/en/timezones.others.php

OK, CET is bad example. But it is the same with WAT (I use in examples too) and is is not on the 'blacklist'.

So add please WAT (and may be some more 'obsolete' timezones) to the blacklist.

For local time it works as everyone expecting. Automatic handling of normal/summer time is simply great.

But I still don't know how to set input timezone to UTC+n (when I have to use such 'bad' timezone) without searching for some place where they use such time offset from UTC I need for the whole year. The searching is strange and tend to generate errors (for some states is used timezone  political decision and it could change).

I miss in all answers before what I get in the last answer. Something like 'continent/location type is preferred and the others are only because backward compatibility' Please use only continent/location, the rest could behave unexpectedly. And it's all. If this will be in the documentation (if is this true) it will be enough. But here is still question I have in previous paragraph.