so, my MS SQL box is EST (currently observing DST), so its UTC -4:00
I had a user with TimeZone (in LIRU) set to Eastern Daylight Time -5:00
In the database it said "America / Atikokan"
Only 1 user had an explicit Timezone. (All others were NULL, which makes Aware use server default for them)
So the 1 user was showing times 1 hour off - because Eastern is currently in Daylight Savings.
But 1 month ago, the times would have been showing correct.
So its odd to me that when the US starts DST, that any user that had explicitly set a timezone will start having incorrect times,
UNLESS they go change their timezone... and even then, I'd have to set to "Atlantic Daylight Time -4" or "GMT -4".
I don't know if this is an Aware implementation issue, or Kendo, or if Kendo doesn't know we are in DST.
For systems where all your users are in the same TZ as the server, its not an issue. Because you wouldn't set this in each SystemUser record.
Timezone. EST vs. EDT
Timezone. EST vs. EDT
Click Here to see a collection of my tips & hacks on this forum. Or search for "JaymerTip" in the search bar at the top.
Jaymer
Aware Programming & Consulting - Tampa FL
Jaymer
Aware Programming & Consulting - Tampa FL
Re: Timezone. EST vs. EDT
This is an issue and we get it two times a year with lots of tickets.
The solution is easy of course, a User must go in and update their TZ, unfortunately most users these days object to doing anything to help themselves and say "the system to be smart enough to do it itself".
I guess this is hard to implement as every timezone has Daylight savings start and end on different dates (Australia doesn't do same ON/OFF dates as USA etc). But if there was an inbuilt solution it would be nice.
As a side point we get a lot of users complain about the options in the drop down on Timezone, mostly US users as they say "these aren't how we label timezones in the States". Of course, the system needs to be more international than just US users, but I guess the US timezones should make sense to US users (I have no idea if they do or not, I'm an Aussie).
The solution is easy of course, a User must go in and update their TZ, unfortunately most users these days object to doing anything to help themselves and say "the system to be smart enough to do it itself".
I guess this is hard to implement as every timezone has Daylight savings start and end on different dates (Australia doesn't do same ON/OFF dates as USA etc). But if there was an inbuilt solution it would be nice.
As a side point we get a lot of users complain about the options in the drop down on Timezone, mostly US users as they say "these aren't how we label timezones in the States". Of course, the system needs to be more international than just US users, but I guess the US timezones should make sense to US users (I have no idea if they do or not, I'm an Aussie).
Rod. Aware V9 (latest build), Developer Edition, on OS Linux (Ubuntu) using GUI hosted on AWS EC2, MYSQL on AWS RDS
Re: Timezone. EST vs. EDT
3 years later - same issue still, if anyone has an elegant solution to this, pls share
Rod. Aware V9 (latest build), Developer Edition, on OS Linux (Ubuntu) using GUI hosted on AWS EC2, MYSQL on AWS RDS
Re: Timezone. EST vs. EDT
Don't know about the US, but in Europe (when we all switch on the same day), I have my server set to auto switch between GMT and GMT+1 (British Summer Time) and then an attribute in systemsetting called HoursFromServer (+ or - integer number)
Then, when I need to calculate a time I use FlightLog.Flightstart=TIME_ADD(TIMESTAMP(1,1,1970,CURRENT_HOUR,CURRENT_MINUTE),SystemSettings.HoursFromServer)
In my case I'm recording start and stop times and don't care about the date but you could equally use TIME_ADD(CURRENT_TIMESTAMP,SystemSettings.HoursFromServer)
Using this method, the user never needs to change anything - they don't even need a time zone setting. The problem I always found with AIM is that if a manager in one time zone is checking a colleague's appointments in another time zone, the manager will have to either switch time zones or do some mental arithmatic to arrive at the actual (local) time of the appointment. In my case If I as a UK resident want to see what time a flight took off in Belgium, I always know that the time I am looking at is Belgium Local time.
Might not be the most elegant solution but it works from me. In continents where not all clocks change on the same day, it might need some tweaking. I should also add that in my case, my customers (gliding clubs) have discreet Business spaces and their members are all local. So I can see how this wouldn't work where a single company has employees across the time zones - but hopefully it's given some food for thought
Then, when I need to calculate a time I use FlightLog.Flightstart=TIME_ADD(TIMESTAMP(1,1,1970,CURRENT_HOUR,CURRENT_MINUTE),SystemSettings.HoursFromServer)
In my case I'm recording start and stop times and don't care about the date but you could equally use TIME_ADD(CURRENT_TIMESTAMP,SystemSettings.HoursFromServer)
Using this method, the user never needs to change anything - they don't even need a time zone setting. The problem I always found with AIM is that if a manager in one time zone is checking a colleague's appointments in another time zone, the manager will have to either switch time zones or do some mental arithmatic to arrive at the actual (local) time of the appointment. In my case If I as a UK resident want to see what time a flight took off in Belgium, I always know that the time I am looking at is Belgium Local time.
Might not be the most elegant solution but it works from me. In continents where not all clocks change on the same day, it might need some tweaking. I should also add that in my case, my customers (gliding clubs) have discreet Business spaces and their members are all local. So I can see how this wouldn't work where a single company has employees across the time zones - but hopefully it's given some food for thought
Rocketman
V8.7 Developer Edition. Server 2016 Standard edition. MySql 5.5
V8.7 Developer Edition. Server 2016 Standard edition. MySql 5.5