> What does use getlocale is time.strptime and datetime.datetime.strptime

calendar.LocaleTextCalendar also uses getlocale() and getdefaultlocale(). The result from getdefaultlocale() cannot be set via setlocale() in Windows, which also breaks resetlocale().

    >>> locale.getdefaultlocale()
    ('en_GB', 'cp1252')
    >>> locale._build_localename(locale.getdefaultlocale())
    'en_GB.cp1252'

This is doubly invalid. It's a BCP-47 locale name with an encoding that's not UTF-8. As of Windows 10 v1803, UTF-8 is supported in ucrt locales, and for BCP-47 locale names, only UTF-8 is allowed to be set explicitly. (If not set to UTF-8 explicitly, then ucrt implicitly uses the given locale's legacy ANSI code page.) Even if something other than UTF-8 were allowed, ucrt will not accept a code page with a "cp" prefix.

Default LocaleTextCalendar case:

    >>> c = calendar.LocaleTextCalendar()
    >>> try: c.formatweekday(1, 10)
    ... except Exception as e: print(e)
    ...
    unsupported locale setting

It works as long as setting the locale succeeds and it can restore the original locale. For example, setting "es" (Spanish):

    >>> c = calendar.LocaleTextCalendar(locale='es')
    >>> locale.setlocale(locale.LC_TIME, 'C')
    'C'
    >>> c.formatweekday(1, 10)
    '  martes  '

Now try with the current locale as a BCP-47 locale name.

    >>> locale.setlocale(locale.LC_TIME, 'en')
    'en'

The parsed getlocale() result is, like with the default locale, doubly invalid. It's a BCP-47 locale name with an encoding that's not UTF-8, and the 'ISO8859-1' codeset is meaningless to ucrt.

    >>> locale.getlocale(locale.LC_TIME)
    ('en_US', 'ISO8859-1')

So restoring the locale fails:

    >>> try: c.formatweekday(1, 10)
    ... except Exception as e: print(e)
    ...
    unsupported locale setting

and it's still set to "es":

    >>> locale.setlocale(locale.LC_TIME)
    'es'