pytz

localize not normalized?

Asked by Jochen Tackenberg

When I create a datetime object and localize it with pytz.timezone('Europe/Berlin') and call normalize on the same object immediately after, the utcoffset and the hour differ for the moment of dst transition from winter to summer.

Example:

In: local_time = pytz.timezone('Europe/Berlin')

In: local_time.localize(datetime.datetime(2017, 3, 26, 2))
Out: datetime.datetime(2017, 3, 26, 2, 0, tzinfo=<DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>)

In: local_time.normalize(local_time.localize(datetime.datetime(2017, 3, 26, 2)))
Out: datetime.datetime(2017, 3, 26, 3, 0, tzinfo=<DstTzInfo 'Europe/Berlin' CEST+2:00:00 DST>)

Is this a feature or a bug!?

Best

Jochen

Question information

Language:
English Edit question
Status:
Expired
For:
pytz Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Launchpad Janitor (janitor) said : 		#1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
Stuart Bishop (stub) said : 		#2

I think it is a bug. I don't know if it is fixable.

2017-3-26 02:00 in Europe/Berlin did not exist, as the clocks skipped forward 1 hour at that instant. The two times are equivalent, despite their string representations being the same, so we are not losing any information. I would say the result from localize is an incorrect representation, because that wallclock time never happened, and the result from using normalize correct.

Revision history for this message
Jochen Tackenberg (jochen-tackenberg) said : 		#3

Ok, thanks for the clarification.

Am 09.11.2017 12:19 nachm. schrieb "Stuart Bishop" <
<email address hidden>>:

> Your question #659852 on pytz changed:
> https://answers.launchpad.net/pytz/+question/659852
>
> Status: Expired => Answered
>
> Stuart Bishop changed the question status:
> I think it is a bug. I don't know if it is fixable.
>
> 2017-3-26 02:00 in Europe/Berlin did not exist, as the clocks skipped
> forward 1 hour at that instant. The two times are equivalent, despite
> their string representations being the same, so we are not losing any
> information. I would say the result from localize is an incorrect
> representation, because that wallclock time never happened, and the
> result from using normalize correct.
>
> --
> You received this question notification because you asked the question.
>

Revision history for this message
Launchpad Janitor (janitor) said : 		#4

This question was expired because it remained in the 'Open' state without activity for the last 15 days.