the bot uses GMT time
far as i know there is no setting for adding offset
Indeed. Rubi-Ka Universal Time (AKA GMT or UTC time) should match that of what the bot displays. (Shift+F11?). There are way to many timezones and different rules to follow, and there is no guarantee that everyone in your org is living in the same time zone...or if they are living in the same time zone there is no guarantee that they follow the same rules.
A great example is Arizona in the states. The state has elected to not follow the US Daylight Savings Time rules, however the Navajo Nation Reservation which is spread across multiple states follows daylight savings time so that the entire Navajo nation is in sync. Try programming this and every other exception to the rules into your program and you'll quickly find you're making mistakes and timestamps are way off, and it becomes a general mess.
And that's what
Coordinated Universal Time (AKA UTC time) is for. UTC is also referred to by the military and civil aviation as Zulu time. GMT is an old term that should be equivalent, but there are many time implementations that mistakenly list GMT time as UTC+1 during European Summer Time, which will create no end to frustration when you try and coordinate across time zones.
I've found that the best solution for dealing with this in code is converting UTC time to a UNIX time stamp and shoving that as an integer (not timestamp) into the database. (A Unix Time Stamp is the number of seconds elapsed since midnight UTC of January 1, 1970, not counting leap seconds.) That way you can be sure your code will always play by the expected set of time rules instead of the rules of your database, or Operating System, or whatever...
Even though a Unix timestamp is not UTC time, it is generally accurate enough given that clock drift between systems is inevitable.
Hope that gives you an understanding of why the bot follows UTC time and not your local time zone.
Total Members: 
Guests: 176
Hidden: 0
Users: 0
