Skip to content

BUG: Timestamp.weekday_name uses UTC instead of given timezone #17354

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
evanunderscore opened this issue Aug 28, 2017 · 3 comments · Fixed by #17377
Closed

BUG: Timestamp.weekday_name uses UTC instead of given timezone #17354

evanunderscore opened this issue Aug 28, 2017 · 3 comments · Fixed by #17377
Labels
Bug Timezones Timezone data dtype
Milestone

Comments

@evanunderscore
Copy link

evanunderscore commented Aug 28, 2017

Code Sample, a copy-pastable example if possible

import pandas as pd

# Create a Timestamp for 11pm Monday 28th
ts = pd.Timestamp('2017-08-28 23:00:00')
# Both weekday() and weekday_name indicate this is a Monday
assert ts.weekday() == 0
assert ts.weekday_name == 'Monday'

# Now localize the timezone
ts = ts.tz_localize('EST')
# weekday() still says Monday, but weekday_name says Tuesday!
assert ts.weekday() == 0
assert ts.weekday_name == 'Tuesday'

Problem description

For pd.Timestamp objects with timezone information, the weekday_name attribute appears to give the name of the weekday in UTC (in the above example, this would be 2017-08-29 04:00:00), whereas weekday() uses local time. I could find no mention of this difference in the documentation for weekday and weekday_name. I would expect both to work in the given timezone.

Expected Output

Expected:
>>> pd.Timestamp('2017-08-28 23:00:00', tz='EST').weekday_name
'Monday'

Actual:
>>> pd.Timestamp('2017-08-28 23:00:00', tz='EST').weekday_name
'Tuesday'

Output of pd.show_versions()

INSTALLED VERSIONS

commit: None
python: 3.6.1.final.0
python-bits: 64
OS: Windows
OS-release: 10
machine: AMD64
processor: Intel64 Family 6 Model 58 Stepping 9, GenuineIntel
byteorder: little
LC_ALL: C
LANG: None
LOCALE: None.None

pandas: 0.20.3
pytest: None
pip: 9.0.1
setuptools: 36.2.7
Cython: None
numpy: 1.13.1
scipy: None
xarray: None
IPython: None
sphinx: None
patsy: None
dateutil: 2.6.1
pytz: 2017.2
blosc: None
bottleneck: None
tables: None
numexpr: None
feather: None
matplotlib: None
openpyxl: None
xlrd: None
xlwt: None
xlsxwriter: None
lxml: None
bs4: None
html5lib: None
sqlalchemy: None
pymysql: None
psycopg2: 2.7.3.1 (dt dec pq3 ext lo64)
jinja2: 2.9.6
s3fs: None
pandas_gbq: None
pandas_datareader: None

@evanunderscore evanunderscore changed the title Timestamp.weekday_name uses UTC instead of local timezone Timestamp.weekday_name uses UTC instead of given timezone Aug 28, 2017
@gfyoung gfyoung added Bug Timezones Timezone data dtype labels Aug 28, 2017
@gfyoung
Copy link
Member

gfyoung commented Aug 28, 2017

Oops. ¯ \ _ (ツ) _ / ¯

PR to patch this is welcome!

@jreback
Copy link
Contributor

jreback commented Aug 28, 2017

this is correct for a DTI, but the impl for Timestamp is not converting to local timestamps (and Timestamp.weeday is in the super class. should be an easy fix.

@jreback jreback added this to the Next Major Release milestone Aug 28, 2017
@jreback
Copy link
Contributor

jreback commented Aug 28, 2017

needs (see _get_field). note that we should make a _get_named_field (similar to _get_field) to handle the dispatch, and have weekday_name call this (its the only one that calls get_date_name_field atm).

        val = self.value
        if self.tz is not None and not _is_utc(self.tz):
            val = tz_convert_single(self.value, 'UTC', self.tz)

@jreback jreback changed the title Timestamp.weekday_name uses UTC instead of given timezone BUG: Timestamp.weekday_name uses UTC instead of given timezone Aug 28, 2017
@jreback jreback modified the milestones: 0.21.0, Next Major Release Aug 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Timezones Timezone data dtype
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants