9

Example

 import pytz
 b=pytz.timezone('Europe/Rome')
 c=pytz.timezone('Europe/Berlin')

These two timezones have different names but represent the same thing, however

  • b==c returns false
  • b.zone is different than c.zone

Is there any way to see that b is in reality equal to c?

The concrete problem is that I have to convert the timezone of a pandas data frame, but only if this zone is different than let's say c. The original timezone might be b and in this case I do not want to convert as it would be a lost of time to convert b into c (since they represent the same time zones at the end....)

Thanks for any help.

Update: changed 'CET' into 'Europe/Rome' to make sure that the timezones are the same in the example, using the feedback from an answer

Mannaggia
  • 4,559
  • 12
  • 34
  • 47

3 Answers3

8

They do not represent the same thing.

  • "CET" is always UTC+01:00

  • "Europe/Berlin" alternates between CET (UTC+01:00) in the winter, and CEST (UTC+02:00) in the summer.

See also:

With regards to the edit, Europe/Rome is a distinct time zone. It is not the same as Europe/Berlin, nor Europe/Zurich, nor Europe/Amsterdam. At least not for their entire histories.

If you compare their definitions (using the links in the prior paragraph), you'll see that these each aligned to the "EU" rule for CET/CEST at some point in their past. Rome and Berlin since 1980, Zurich since 1981, and Amsterdam since 1977. Before those dates, they differed significantly. Other time zones have different rules as well.

If you're interested in the history of these zones, I suggest reading through the europe file in the TZ data. The comments alone are quite interesting.

On the other hand, if you are only working with modern dates, where all zones are following the same rules and offsets, then you could consider these substitutable - at least as long as they don't change in the future.

Also, there are some time zones that are just aliases and are completely interchangeable. In the TZ data, they're called "links". For example, you can see here that Europe/Vatican and Europe/San_Marino are both linked to Europe/Rome, and are therefore equivalent.

Community
  • 1
  • 1
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • ok, then consider my example with time zone "Europe/Rome" instead of "CET". I think we can conclude that now they are the same but there is still not an intuitive way to find this out – Mannaggia Jun 18 '14 at 08:21
  • 1
    @Mannaggia: Why do you think Europe/Rome and Europe/Berlin timezones are the same? Even if the utc offsets are the same today, they might be different in the past or in the future. – jfs Jun 20 '14 at 02:06
  • @J.F.Sebastian: as long as they do not differ they should be the same. Also, I expect the two classes implementing these type to have exactly the same implementation and state variables.Therefore I do not see any reason why they should differ. – Mannaggia Jun 20 '14 at 07:46
  • @Mannaggia: all timezones with DST transitions are implemented using the same class. It does mean that any instances should be the same e.g., all integer in Python 3 are instances of `int` class. It doesn't mean that all integers should be the same `1 != 2` (though it is easy using version-specific `ctypes` magic to make them equal (with detrimental effect on your program)). – jfs Jun 20 '14 at 08:33
  • @J.F.Sebastian: the point is that 'Europe/Rome' is an alias of 'Europe/Berlin' or 'Europe/Zurich' or 'Europe/Amsterdam', etc. So we got plenty of time zones which are an alias of the same underlying concept. Is this not an unnecessary complexity? I think this is not the same as comparing two different integers which are different instances of the same type. Here the type is timezone and the instances are Europe/Rome and Europe/Berlin... it is like saying that 1 != (2-1) – Mannaggia Jun 20 '14 at 09:23
  • @Matt Johnson: thanks for the deep explanation, at the end I needed a fast solution to my concrete problem which was provided by another answer, nevertheless I am grateful for your input – Mannaggia Jun 23 '14 at 15:12
  • @Mannaggia: I don't think `'Europe/Rome'` timezone is an alias for `'Europe/Berlin'` even if it happens that they use the same rules **today**. Do you have any reference that says that they are aliases and not separate completely independent timezones? – jfs Jun 26 '14 at 10:46
  • @J.F. Sebastian: I do not have any reference but as pointed out by MattJohnson they apparently used to differ before the '80s, fact is that as of today they are the same and most likely they will be the same for many years to come... – Mannaggia Jun 26 '14 at 12:28
6

It's kind of ghetto, but I could compare the offsets of both timezones against a given a timestamp.

from datetime import datetime
today = datetime.today()
b.utcoffset(today) == c.utcoffset(today)
chrisaycock
  • 36,470
  • 14
  • 88
  • 125
1

If the only reason for not wanting to convert is because of inefficiency, I would question whether this is really necessary. There is a good blog post by Wes McKinney on vectorized datetime conversion http://wesmckinney.com/blog/?p=506. As an example, for a series with 1e6 rows

In [1]: from pandas import *
In [2]: import numpy as np
In [3]: rng = date_range('3/6/2012', periods=1000000, freq='s', tz='US/Eastern')
In [4]: ts = Series(np.random.randn(len(rng)),rng)
In [5]: %timeit ts.tz_convert('utc')
100 loops, best of 3: 2.17 ms per loop
mgilbert
  • 3,495
  • 4
  • 22
  • 39