Please, abandon RFC-3339!

[pps83]

Seems like a nice idea to use that standard format, but it's really not that great idea. For a simple reason: it opens endless can of worms dealing with EDT/EST transition and adds extra pain for those located outside of Eastern timezone. For example, to fetch bars for 9:30-15:00 range one would need to either specify UTC stamps with weirds offsets that change based DST which depends on political rules, and these rules aren't constant and have changed in the past. In C/C++ for example, one cannot even know if DST are in effect in NY timezone if they aren't located in the same timezone! Conversion for DST will apply local rules of whatever locale. In C/C++ it's literally impossible to do that correctly using standard API, one would need to set system timezone to NY to get it working correctly! Otherwise, it will not work correctly. Worst, is that it will appear as if it wokrs, until it stops working when DST rules of the system locale differ with DST rules on NY timezone. But wait, that's not all, there is even worse problem: even if you set your system timezone it will still be buggy. Because regular standard c API in many libs doesn't handle correctly DST transition for dates in the past! Doesn't seem like a big problem, but if somebody builds model or backtests on long timeframes there will be multi-week long gaps where offsets won't be calculated correctly because DST rules prior to 1987 were different from rules that were until 2007 and different from rules that we have today.

How about simply allowing regular times without any timezone offset nonsense? Can you just allow plain simple readable dates just like all other algo APIs have: Use 2020-06-02 for dates, use 9:30 for time. Very simple, no need to get involved with DST and offsets from UTC rules to be able to properly show offsets from UTC. Simply allow 2020-06-02T9:30:00 without timezone. Server side parsing RFC dates is easy to convert to UTC time, and, as long as you store all your trades internally in UTC then everything works fine. But if you internally store trades with NY time then your server may as well have issues dealing with timezones. Also, if you allow simple version string without time offset, then server side you may have issue dealing and converting to/from UTC from NY times in the past. These are historical DST rules for NY timezone: https://en.wikipedia.org/wiki/Eastern_Time_Zone#Daylight_saving_time