Haha, it looks like the server is on UTC time and my machine is on EDT so we have a mismatch on output although the times are the same. I should be doing a timezone-aware comparison! How ironic. I'll make the necessary changes sometime this week.

If it helps, dates passed through this library are merely data labels, so converting to a time zone aware format isn’t helpful for anything it does; however, I so see how someone sending in with TZ aware offset formats would want it to come back in that same format. Few financial market quote sources use this more expensive format, so am not sure this’ll be worth the added cost. @LeeDongGeon1996 any thoughts here?

I'll have a look tonight.

Hi, first of all, thanks for your contribution :)

@DaveSkender Do you mean that datetime data in financial markets is usually provided in not timezone-aware form?
I think it's worth it in terms of backward-compatibility. If there's someone having timezone-aware data, they will not care about whatever their date format is and struggle with the error from timezone-aware data.

Hi, first of all, thanks for your contribution :)

@DaveSkender Do you mean that datetime data in financial markets is usually provided in not timezone-aware form? I think it's worth it in terms of backward-compatibility. If there's someone having timezone-aware data, they will not care about whatever their date format is and struggle with the error from timezone-aware data.

Yes, it'll usually comes from sources without timezone offset information, it comes at intrinsic regional market time or UTC time, without any offset information. For example, most U.S- based market data is in Eastern Time Zone, but someone could encode it with timezone offest information as Z-5 if they wanted to.

This is really a matter of how much cost (e.g., to performance and extra features) do we want to bear to accommodate its use in quotes people provide. I don't think I'll change the .NET library from DateTime to DateTimeOffset either, it's way too expensive and can get really goofy, with little value. It's possible that I'm overthinking this as there might be some simple tweak here that just works.

Hi @DaveSkender & @LeeDongGeon1996, thank you for the great library! I appreciate the feedback. Please see below how I encountered this error.

stoch_rsi_results = si.get_stoch_rsi(quotes_list, R, S, G, M).remove_warmup_periods()
rsi_df = pd.DataFrame([ (r.date, r.stoch_rsi, r.signal) for r in stoch_rsi_results ], columns=['TimeStamp','stoch_rsi','rsi_signal'])

The TradeStation API returns data in UTC time with a 'Z' marker to indicate the timezone: TradeStation API specification. I convert this datetime to Eastern for New York exchanges before calling the stock-indicators functions. If someone is using this library for other exchanges, they may use that exchange's local timezone. I then load the results to a pandas DataFrame to merge back in with my other data based on datetime, which I've named TimeStamp. I convert both DataFrames that I'm merging to Eastern time for New York exchanges. As long as they are both timezone aware, this works. It's okay if it changes timezones as long as it knows which timezone it has changed to.

The errors in the GitHub build are due to trying to compare them as strings in the tests I added. I'll put a fix in for those shortly.

I don't think I'll change the .NET library from DateTime to DateTimeOffset either, it's way too expensive and can get really goofy, with little value. It's possible that I'm overthinking this as there might be some simple tweak here that just works.

It doesn't seem to need a tweak in the C# code. It comes back timezone aware from what I can tell. It just has one too many zeros in the fraction of seconds. The use of the Python dateutils isoparse function compensates for that adequately.

Concerning the computational cost, it doesn't seem to increase unless someone uses a timezone aware datetime. The dateutils function seems comparable to the datetime function in computation speed. Also, I give 2000 rows for the tz aware benchmark test, which is four times the data in the default dataset. Maybe this is the cause of the increased computation time.

I fixed the tests: just needed to compare them as dates.

I didn't push the added benchmarks I ran because the docs say not to update the Excel file, but I have those stashed if you want me to. Just let me know.

I have yet one more set of fixes to make. While I normally put standard library imports before third-party with clearer separation, I tried to follow the format of the library. I like 'import' statements together and 'from' statements together. I'll fix that quickly.

Sorry for late reply, I'll have a look tonight.

@claytonEtillman I think that your words are reasonable and this feature will be helpful to users. One thing that I couldn't fully understand, could you explain more about this?

It just has one too many zeros in the fraction of seconds.

Ohh.. now I get your words. I'm not 100% sure, but think that this is not a problem about Python datetime parsing. It's a problem of parameter for C-Sharp datetime "o" .
Please refer to https://learn.microsoft.com/en-us/dotnet/api/system.datetime.tostring?view=net-7.0#code-try-6
I'll look into more on this weekend.

EDIT:
The problem is from where I split a datetime string, whick comes from C# datetime. It originally comes with well-formed value, 2008-06-15T21:15:07.0000000, but I remove the last zero from the code. That makes it incorrect-form of datetime string, eventually failed to parse on Python datetime

datetime.fromisoformat('2008-06-15T21:15:07.0000000'[-1])

Traceback (most recent call last):
ERROR!
File "<string>", line 15, in <module>
ValueError: Invalid isoformat string: '0'

Please let me know if there's sth wrong.