Think about abandoning timezone abbreviations map in my.core.time

With the DST shift in the UK, DST fails to parse, because the current version of the provider depends on 'current time'.

HPI/my/core/time.py

Line 8 in a946e23

pytz.timezone(x).localize(datetime.now()).tzname(): pytz.timezone(x)

While it's possible to get rid of this, TZ abbreviations are inherently ambiguous, so there is no way to guess this correctly without user overrides.

Perhaps the best is to just treat them as local time, and rely on the location provider #96

Had a similar issue seanbreckenridge/HPI@07e0a2d

We properly worked around it google_takeout_export (still hacky with force_abbreviations etc, but using abbreviations is inherently flaky, so not much we can do)

I ported the implementation from google_takeout_export into

HPI/my/core/time.py

Lines 50 to 59 in 5799c06

    
           def localize_with_abbr(dt: datetime_naive, *, abbr: str) -> datetime_aware: 
        
               if abbr.lower() == 'utc': 
        
                   # best to shortcut here to avoid complications 
        
                   return pytz.utc.localize(dt) 
        
               tz = abbr_to_timezone(abbr) 
        
               # this will compute the correct UTC offset 
        
               tzinfo = tz.localize(dt).tzinfo 
        
               assert tzinfo is not None  # make mypy happy 
        
               return tz.normalize(dt.replace(tzinfo=tzinfo))

(mostly by accident), but there is nothing using it in HPI at the moment, except legacy takeout modules.

	def localize_with_abbr(dt: datetime_naive, *, abbr: str) -> datetime_aware:
	if abbr.lower() == 'utc':
	# best to shortcut here to avoid complications
	return pytz.utc.localize(dt)

	tz = abbr_to_timezone(abbr)
	# this will compute the correct UTC offset
	tzinfo = tz.localize(dt).tzinfo
	assert tzinfo is not None # make mypy happy
	return tz.normalize(dt.replace(tzinfo=tzinfo))