Wrong time stamp for 1h time frame for versions after 0.2.44

[indra5534]

Describe bug

Whenever I am trying to download stock data for 1h time frame it shows wrong time frame. This problem was not present in 0.2.44 and previous versions. It was easier to use when it used to give output in local time frames

Simple code that reproduces your problem

import yfinance as yf

print("\nyfinance version:", yf.version)
ticker = 'AAPL'
interval = '1h'
data = yf.download(ticker, period='1mo', interval=interval)

print("\nLast 7 Close Prices:")
print(data['Close'].tail(7))

Debug log

I downloaded stock data of AAPL in 0.2.44 version this is the print out.
Last 7 Close Prices:
Datetime
2024-11-25 11:30:00-05:00 230.206802
2024-11-25 12:30:00-05:00 230.414993
2024-11-25 13:30:00-05:00 230.684998
2024-11-25 14:30:00-05:00 230.520004
2024-11-25 15:30:00-05:00 232.880005
2024-11-26 09:30:00-05:00 234.360001
2024-11-26 10:30:00-05:00 235.139999

But when I downloaded stock data of AAPL in 0.2.50 version this is the print out.
Ticker AAPL
Datetime
2024-11-25 16:30:00+00:00 230.206802
2024-11-25 17:30:00+00:00 230.414993
2024-11-25 18:30:00+00:00 230.684998
2024-11-25 19:30:00+00:00 230.520004
2024-11-25 20:30:00+00:00 232.880005
2024-11-26 14:30:00+00:00 234.360001
2024-11-26 15:30:00+00:00 235.313507

Bad data proof

yfinance version

0.2.50

Python version

3.10

Operating system

No response

[paulmcq]

Look at the time-zone part of the times. First line from version 0.2.44 says 2024-11-25 11:30:00-05:00 230.206802, whereas in version 0.2.50 it is 2024-11-25 16:30:00+00:00 230.206802. That looks like 5 hours later, which is what the time-zone is telling you: -05:00 = UTC-5 = US Eastern Standard Time = New York.
IOW: 0.2.44 reports times in the zone of the stock exchange, whilst 0.2.50 is showing UTC.
I would hazard a guess that the price difference in the last row "235.139999" vs "235.313507" could be due to corrections still in flight for the latest market session??

[ValueRaider]

Recent versions standardised the handling of timezones:

yfinance/tests/test_prices.py

Lines 47 to 50 in 0c89fcd

	def test_download_multi_small_interval(self):
	use_tkrs = ["AAPL", "0Q3.DE", "ATVI"]
	df = yf.download(use_tkrs, period="1d", interval="5m")
	self.assertEqual(df.index.tz, _dt.timezone.utc)

download is intended for multiple tickers potentially across multiple timezones. What is local then?

[ValueRaider]

@indra5534 don't need to repost the screenshots.

One option is localizing to the most common timezone.

[indra5534]

For 1h time frame api gives generalized time zone. For other time frames like 15m, 30m it gives localized time zone. I was trying to get data from user input time frame. But due to this I am unable to do so. For 1h it needs conversations to to localized time zone, for other time frame it doesn't need so. Please help.
Version 0.2.44 used to give data for all time frames in the same time zone(localized).

[ValueRaider]

Here's the problem

yfinance/yfinance/multi.py

Line 109 in 0c89fcd

if interval[1:] in ['m', 'h']:

[ValueRaider]

That isn't obviously a yfinance error. Comprehend what Pandas is saying.

[indra5534]

Ok fixed. thanks. If possible please remove default time zones for future versions. like 1h time frame has UTC time zone. and all other time frame dont have any default time zones. Its hard for me to adjust my code for every versions released.

[ValueRaider]

This isn't fixed. My last message referred to a different error that you deleted.

[indra5534]

Sorry I meant to say, I removed time zones from that code that fixed it, it is wrong to ask you guys to Debug my code.

If you can standardize time zone for future updates that would be great. We don't have to localize or remove time zones from time stamps for various timeframes that makes accessing mutiple time frame at onec easier. That's it.