I’d think you want be setting the active time zone, rather than trying to set it on the field...

I haven't considered setting the timezone - it might have been easier than replacing DateTimeField with a SerializerMethodField.

Either way I think the current behaviour is unexpected.

I think it's reasonable to expect this snippet:

field = serializers.DateTimeField(
    default_timezone=pytz.timezone('Asia/Kolkata'),
    format=''%d/%m/%Y %H:%M'
)

to produce the date in Asia/Kolkata and not UTC as it is now.

Current behavior is consistent with Django's
DRF documentation should probably add a link to it but I don't see this as an unexpected behavior.

Current behavior is consistent with Django's

Fair enough.

I'll close the PR.

Following @carltongibson advice, is this also exepcted behaviour:

def test_should_render_date_time_in_active_timezone(self):
    field = serializers.DateTimeField(default_timezone=self.kolkata, format=self.date_format)
    dt = datetime.datetime(2018, 2, 8, 14, 15, 16, tzinfo=pytz.utc)

    with timezone.override(self.kolkata):
        rendered_date = field.to_representation(dt)

    rendered_date_in_timezone = dt.astimezone(self.kolkata).strftime(self.date_format)

    assert rendered_date == rendered_date_in_timezone

The rendered date is not in the current timezone (kolkata):

E   AssertionError: assert '08/02/2018 14:15' == '08/02/2018 19:45'
E     - 08/02/2018 14:15
E     ?              --
E     + 08/02/2018 19:45
E     ?             ++

It looks like the timezone is only enforced for ISO 8601.
Doesn't look close to what I said previously :(
Not even sure why it's not enforced in any case.

@hakib Can you push that test as is. We'll have a look.

It looks like the timezone is only enforced for ISO 8601.

That's exactly the point - right now it's not possible to provide a format other than ISO-8601 and have the date render in a timezone other than the default one.

Just to clarify on the use case here, i'm usually working with UTC so I never noticed it. In this particular scenario I had a custom renderer aimed at a printer so I needed to make sure the date is rendered at the client's local time.

Closing in favour of #5833. Thanks @hakib!