BeginTime EndTime timezone ?

[gomifromparis]

Hi,

Problem seems that BeginTime and EndTime give you an int that represents their local time. eg 830 for CME session manager BeginTime.

Shouln't this be converted to local time of the computer, or else the tests with Time[0], which is in local TZ, have no chance to work ?

Thanks

[NinjaTrader_JoshP]

The returns will return it to you as defined in the Session Manager. Any time zone conversions will need to be handled by the code.

[gomifromparis]

Well basically that implies at least that documentation is not accurate:

Documentation of BeginTime says
// Checks if the current time is past the session beginning time
if (ToTime(Time[0]) >= Bars.Session.SessionsOfDay[0].BeginTime)
Print("Time is past the session beginning time.");
}

This will only work if you live in the TZ of the instrument's session. So if you are trading e-mini, this code will only work if you live in CET.

Could you give an example on how to solve a simple problem : is the currentbar past session begin time ?

Thanks

[NinjaTrader_JoshP]

The example is designed for the most basic case scenario. If you need to do time zone conversion that is an additional step you will need on top of it. All you have to do is add/subtract whichever amount of hours is needed to bring the data into the desired time zone. Adding 10000 will add one hour, subtracting will remove 1 hour.

[gomifromparis]

All you have to do is add/subtract whichever amount of hours is needed to bring the data into the desired time zone. Adding 10000 will add one hour, subtracting will remove 1 hour.

Wow, that's a cool use of the TimeZone concept. Making all the hard work to create the session manager with TZ management, only to have end users having to add or substract +10000s, that's a big step forward.

This idea to get us session times using ints is very strange. "Basic" developers won't be able to use it because it's not in local TZ, and everything else in NT is localtime. So what could be the use ?

"Advanced" developers will need to convert it back to TimeSpan to be able to do anything useful with it. So why this decision ?

Time calculation with ints seem cool but it will be a pain. That's why DateTime structs were invented. Do you really think time=(time+10000)%240000; is simpler to use than time.AddHours(1); ?

The only advantage is that people can write time>153000 instead of time>TimeSpan(15,30,00) but is it really worth it ??


Anyway I believe there is a bug : for CME session I get 830 and not 83000.


PS : for those interested in TZ management, here's some code that allows you to mimick old ChartControl.SessionBegin and SessionEnd

private TimeSpan ConvertNTToTimeSpan(int timetoconvert)
{

//this code is OK but bug in NT7    
/*
    int hours = timetoconvert / 10000;
    timetoconvert = timetoconvert % 10000;
    int mins=timetoconvert / 100;
    int secs=timetoconvert%100;
*/

//wrong code but workaround
    int hours=timetoconvert / 100;
    int mins=timetoconvert%100;
    int secs=0;
    
    return new TimeSpan(hours,mins,secs);
}
    


private void RecalcStartEndTime(DateTime time)
{
    //we look for session of the correct day
    SessionOfDay sess=null;
    foreach (SessionOfDay sessiterator in BarsArray[0].Session.SessionsOfDay)
        if (sessiterator.BeginDay==time.DayOfWeek)
        {
            sess=sessiterator;
            break;
        }
    
    DateTime ST;
    DateTime ET;
        
    ST=TimeZoneInfo.ConvertTime(time.Date.Add(ConvertNTToTimeSpan(sess.BeginTime)),Bars.Session.TimeZoneInfo,TimeZoneInfo.Local);
    ET=TimeZoneInfo.ConvertTime(time.Date.Add(ConvertNTToTimeSpan(sess.EndTime)),Bars.Session.TimeZoneInfo,TimeZoneInfo.Local);
    
    Print(ST+" - "+ET);

}

Cool part is you don't have to care about daylight savings date in different time zones. All automatic

example of output (I live in Europe)

04/11/2009 15:30:00 - 04/11/2009 22:15:00
20/10/2009 15:30:00 - 20/10/2009 22:15:00
21/10/2009 15:30:00 - 21/10/2009 22:15:00
22/10/2009 15:30:00 - 22/10/2009 22:15:00
23/10/2009 15:30:00 - 23/10/2009 22:15:00
26/10/2009 14:30:00 - 26/10/2009 21:15:00
27/10/2009 14:30:00 - 27/10/2009 21:15:00
28/10/2009 14:30:00 - 28/10/2009 21:15:00
29/10/2009 14:30:00 - 29/10/2009 21:15:00
02/11/2009 15:30:00 - 02/11/2009 22:15:00
03/11/2009 15:30:00 - 03/11/2009 22:15:00
04/11/2009 15:30:00 - 04/11/2009 22:15:00

[NinjaTrader_Ray]

Thanks for sharing your thoughts.

- In Beta 5, you will see this revamped.

Session.SessionsOfDay.BeginTimeExchange
Session.SessionsOfDay.BeginTimeLocal
Session.SessionsOfDay.EndTimeExchange
Session.SessionsOfDay.EndTimeLocal

All returning DateTime objects.

[gomifromparis]

Hi Ray,

Thanks, that's great news, but you can't return a local time correctly if you don't send in the day it is applied to, because time offset between 2 time zones varies during the year, mainly because of daylight savings change dates that are different in different countries.

SessionOfDay only manages days of the week, and knowing the day of the week is not enough to know the time zones difference. So you can"t deduce BeginTimeLocal from only the day of the week.

Here is what I would suggest :

• either keep BeginTime and EndTime like today (returning Exchange times), but make them TimeSpan and not ints. That allows someone who wants to use them to have something to work with.

• either create methods DateTime BeginTimeLocal(DateTime dateparam) and DateTime EndTimeLocal(DateTime dateparam) that takes a date as parameter, and that finds the correct day of week, fetches the info in the Session manager, and sends it back a local DateTime. So you would send a day as parameter, and you would bet back the Begin and End DateTimes for that day.

PS : if you return Times that don't contain any Date information , I believe the most appropriate object is TimeSpan, not DateTime

Thanks

[NinjaTrader_JoshP]

gomifromparis,

It will contain all the conversions already. The only valid values from these DateTime objects will be DayOfWeek and the time. The actual date portion will not be relevant.

[gomifromparis]

I'm sorry but I don't understand your answer.
To calculate a localtime from a time you need a date.
What date do you use to do the conversion ? Time[0] ?

[NinjaTrader_JoshP]

gomifromparis,

The point is you do not need to do any conversion.

BeginTimeLocal gives you the session definition's begin time already converted to local time which you can then directly compare to Time[0]. The date given is just stuffed in and is irrelevant just like how the date portion of SessionBegin/End in 6.5 was irrelevant. The only relevant pieces of information from these new DateTime objects will be the time portion and the DayOfWeek. Hopefully that is a more clear explanation now.

[gomifromparis]

I'm sorry but no it's not clearer at all.

Could you please give me a direct and precise answer to the following question :

"You CANNOT compute time zone calculations only based on a time, you MUST use an INPUT DATE , because conversion calculations VARIES depending the date you're at (DST issues here).

BeginTimeLocal will give the local begin time AT WHAT DATE ?"

Thanks

[NinjaTrader_Dierk]

Let me try to clarify:
- session definitions in NT7 are not about a particular date (same as 6.5)
- they would hold (per session) a begin and an end time
- these times are provided as local and as exchange time
- since the data type is "Datetime", the .DayOfWeek property would tell you which day of week this session would be on (again, the date itself it totally irrelevant)

So, it up to you to calculate the session time for an actual date (which you needed to provide)

[gomifromparis]

- these times are provided as local and as exchange time

What I'm trying to say here is that you can't provide a local time if you don't know at which date it's calculated.
In France, CME open is sometimes 15:30, and sometimes 14:30, depending on DST dates.
What will you BeginTimeLocal return ? 15:30 or 14:30 ?

[NinjaTrader_JoshP]

gomifromparis,

Local time has always been determined by your PC clock.

[gomifromparis]

Wow, it's clear now you're not willing/able/have time/are able to understand the problem here.

So please be my guest, go implement your BeginTimeLocal. Maybe you'll understand when developing it that it's not possible to do. If you do anyway, it won't work and I'll file a bug.

For the last time : the offset between time zones IS NOT CONSTANT. So you cannot convert a time from a zone to a time to another zone WITHOUT SPECIFYING AT WHAT DATE you're doing the conversion. So there CAN'T BE a BeginTimeLocal that is a constant property, because, as in the example I showed, the times offset DEPENDS OF WHAT DATE you're at.

If only you could spend 3 minutes to actually read this thread and actually try to understand what the problem is about, you would really see there is one. And I wouldn't have to take time to answer "local time is given by your PC clock" posts..... Thanks, Josh, wasn't aware of that....

Final post for me, I'll see what you've done in beta 5.