So being in New Mexico you obviously need the USA related times, because using European times would be awkward for you just the same.
It comes down to this part, I think :
The accepted one would be the one where in our time (Paris, Amsterdam) future opening times are 00:00. This would make it logical to mention your USA time 6 hours earlier (this is just Exchange opening time stuff). Nobody (for program code) would care whether this is ET or CET, as long as we (you !) know that this would be 18:00 = 6pm.
What this requires is a setting which matches the opening of the futures of 6pm. The difficulty for me is to bring across what this would be for you in New Mexico. Example :
If all is right, you are not subject to Daylight Savings. However, the “Exchange” normalized times, are. Exchange won’t be the proper wording (because it would lead to e.g. Chicago), and it is better to refer to the NY time. Thus, whatever that is for you for a setting, it is the New York time you need, and that concurs with the 6pm opening (and 5pm closing).
But
Sadly, NY *is* subject to Daylight Savings and since 3 weeks or so it is “Winter Time” there (the normal time). This will mean that when Summer Time starts in 2024 (Sunday March 10), the opening of the futures will be one hour earlier for you, thus 5pm (closing at 4pm). This will last the whole summer.
Disclaimer : We have more often discussions about this variances in time, but this one I don’t recall; it is special because your Mountain Time Zone (if I am correct) does not have Daylight Saving. The specialty is that in my code (for Netherlands) I have an offset for 1 or 2 (or maybe 3) weeks because of the difference in Daylight Saving start and end, while with you it would last the whole summer.
Maybe others have ideas, but I would not know a solution for how to code this, because it is too easy to make mistakes. We, over here, are not from the CET etc. times, and we also don’t know a thing about the differences between States. I do know that when you travel 4 states, you need to adjust your wristwatch 4 times, because each state tends to have another time. This is not about Daylight Savings (the change of an hour is the same for the USA throughout (except thus the Mountain Time zone), but the individual times are different (and vary for IIRC 3 hours maximum).
And so all I can refer to is the NY time (how ever that is denoted), because I (or we) know the difference with that for us over here : 6 hours (yeah, or 5 hours when we are in the twilight zone of Daylight Savings difference – which happens twice a year).
This is all so stupidly vague for at least me, that “guessing” when the FED will speak / announce new rates, is always a hit and miss because it is not expressed in NY time, but another; maybe other PRT users know definitely in advance whether that is 7pm or 8pm for us, not forgetting about said twilight zone which also may occur coincidentally.
There seems to be a solution in the PRT settings with the hint of “Use Instrument times” after all. But the second hint would be that nobody knows how to set those – at least I don’t as it would be unworkable for me. I would get crazy of all the different times to set in the code, and so I don’t. I use two “variables” only : 1. the knowledge of the “exchange” times, and 2. the incorporation of the Daylight Savings difference.
Ad 1.: For Europe, USA and UK only; would I (Auto-) trade Asian countries as well, I’d probably find a high bridge (not looking at India because that is even more special).
It takes years to grasp all this, I my years seem not to be sufficient yet.
Hopefully others have good hints for you; people from Australia (or New Zealand for that matter) deal with very similar but in other dimensions (like reversed Daylight Savings compared to USA / Europe).
BZZzzzz
.
