4.95 has many new features. Thanks!
You have implemented Time Zones. From what I see, if a Business Object is Intelligent, it receives a built-in Time Zone attribute which when displayed, presents a drop list of all time zones from which to choose. Got that.
Other than having a built-in drop list, I do no see how to make use of the attribute. For example, if I want to put the report generation time stamp in a report, and adjust the time for the local time of the user, I don't see how (or if) I can use this attribute to accomplish this.
Can you please provide a brief description of your concept for this function?
Need to understand concept of new Time Zone function
-
aware_support
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
The whole purpose of the feature is this:
Aware IM will automatically convert timestamps into the timezone of the currently logged in user.
This is essential if you have a hosted server that serves clients located in different timezones. The server works in its own timezone and all timestamps are stored in the database using the timezone of the server. However, if a logged in user indicated that he was located in a different timezone Aware IM would automatically convert the timestamp from the server timezone to the user timezone. So to the user it is as if all his timestamps are for his timezone.
Obviously, for this to work the user has to indicate his timezone when he registers with the system (or when someone registers him) - this is why all objects in the SystemUser group have a TimeZone attribute. If you don't care about timezones (for example, if all your users are in the same timezone), then you don't need to put this attribute on the registration form.
Aware IM will automatically convert timestamps into the timezone of the currently logged in user.
This is essential if you have a hosted server that serves clients located in different timezones. The server works in its own timezone and all timestamps are stored in the database using the timezone of the server. However, if a logged in user indicated that he was located in a different timezone Aware IM would automatically convert the timestamp from the server timezone to the user timezone. So to the user it is as if all his timestamps are for his timezone.
Obviously, for this to work the user has to indicate his timezone when he registers with the system (or when someone registers him) - this is why all objects in the SystemUser group have a TimeZone attribute. If you don't care about timezones (for example, if all your users are in the same timezone), then you don't need to put this attribute on the registration form.
Aware IM Support Team
-
aware_support
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
This is all good. Is it possible to employ the Time Zone attribute on a BO that is not included in the Access Levels?
Point is, my application has Accounts which have Users. I'd like to set the time zone at the account level. I could do this by adding the Account to the Access group - no harm, but not an actual business requirement. I can also run a process to set all users to the same time zone chosen by any one. I prefer this to adding the Account to the access group.
Other thoughts?
Point is, my application has Accounts which have Users. I'd like to set the time zone at the account level. I could do this by adding the Account to the Access group - no harm, but not an actual business requirement. I can also run a process to set all users to the same time zone chosen by any one. I prefer this to adding the Account to the access group.
Other thoughts?
-
aware_support
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
Support I'm trying to understand how time zones are meant to operate. It appears that timestamp attributes stored in the DB are displayed differently depending on the time zone.
This to me makes no sense at all.
If you have an application where a user can make an appointment and it's made for July 15th at 10:00am then it should display as July 15th 10:00am no matter what time zone you are in. I thought that only the Current date/time functions would and should react to changes in time zones. So if a user brought up a calendar it would display Today correctly. Also processes that compare date/times against current date/time stamps would work in the time zone selected.
Further I note that you only display/change timestamp attributes in the time zone selected and not date attributes. So if you have two attributes set to the same value in the DB the timestamp date will change but the date attribute wont. This again to me is very confusing.
As it stands I don't see the benefit of this functionality? Can you explain what I'm doing wrong or misunderstanding as to me this is completely wrong in concept and design.
Cheers Rod
This to me makes no sense at all.
If you have an application where a user can make an appointment and it's made for July 15th at 10:00am then it should display as July 15th 10:00am no matter what time zone you are in. I thought that only the Current date/time functions would and should react to changes in time zones. So if a user brought up a calendar it would display Today correctly. Also processes that compare date/times against current date/time stamps would work in the time zone selected.
Further I note that you only display/change timestamp attributes in the time zone selected and not date attributes. So if you have two attributes set to the same value in the DB the timestamp date will change but the date attribute wont. This again to me is very confusing.
As it stands I don't see the benefit of this functionality? Can you explain what I'm doing wrong or misunderstanding as to me this is completely wrong in concept and design.
Cheers Rod
Watching this post with interest as I'm just about to start using timezones. here are my thoughts.
LET'S SAY IT'S 9:00AM IN ENGLAND. My server is set to GMT. A user in Germany books an appointment for 10:00am local time, so the CURRENT_TIMESTAMP SHOULD RETURN GMT+1 to the local user. The appointment record should have the local time stored surely - otherwise, if a supervisor in - say - the US wants to check the appointment schedule and the times are converted on the fly from GMT to Eastern Seaboard, the US supervisor is going to think the local german rep is seeing people at midnight (ok the sums might be the wrong way round but you get the picture.)
Stored times HAVE to be local times surely. Is this not what is happening Rod
LET'S SAY IT'S 9:00AM IN ENGLAND. My server is set to GMT. A user in Germany books an appointment for 10:00am local time, so the CURRENT_TIMESTAMP SHOULD RETURN GMT+1 to the local user. The appointment record should have the local time stored surely - otherwise, if a supervisor in - say - the US wants to check the appointment schedule and the times are converted on the fly from GMT to Eastern Seaboard, the US supervisor is going to think the local german rep is seeing people at midnight (ok the sums might be the wrong way round but you get the picture.)
Stored times HAVE to be local times surely. Is this not what is happening Rod
Rocketman
V8.7 Developer Edition. Server 2016 Standard edition. MySql 5.5
V8.7 Developer Edition. Server 2016 Standard edition. MySql 5.5
The way it seems to work is that all it does is display timestamp attribute values in the local time. That's it! CURRENT_TIMESTAMP function does not change to reflect the local time. I think that is totally wrong.
So in your example the user in Germany books an appointment for 10am. He brings up the calendar and it displays the current date and time as what is set on your server, 9am! For a start thats confusing to him. He selects 10am as his appointment time. The appointment is added and stored in the db as 10am. Good. But when he now views it, it shows him that it is booked for 11am as it adjusts the displayed time for his timezone!!! So now the guy thinks that he has an appointment at 11am!
The person in the US again would have the time adjusted by their GMT!
Also if you have an audit attribute which is set to CURRENT_TIMESTAMP so you know when the appointment was added it would be stored in the db as 9am, as the server time is used for the CURRENT_TIMESTAMP and so is not adjusted. But then that time as its a timestamp is displayed in his local time so it ends up being correct.
I think its totally unusable as it stands and don't understand why it works this way. I would have thought that you just change the CURRENT Timestamp AND DATE functions so that a user can work with them in their local time zone. Also any processes that use these CURRENT date time functions would work correctly if for example you were trying to display late actions or to do lists etc. If you have a query displayed as a calendar the current day which is highlighted is the day determined by your server.
But I've been hoping that support would come forth with why they did not change the CURRENT functions to reflect local time zones and decided instead to display/adjust ALL timestamp attributes in the local time.
I've misunderstood things before so this would not be the first time if I indeed have it wrong. But to me as it stands it is not only unusable it's wrong.
Cheers Rod
So in your example the user in Germany books an appointment for 10am. He brings up the calendar and it displays the current date and time as what is set on your server, 9am! For a start thats confusing to him. He selects 10am as his appointment time. The appointment is added and stored in the db as 10am. Good. But when he now views it, it shows him that it is booked for 11am as it adjusts the displayed time for his timezone!!! So now the guy thinks that he has an appointment at 11am!
The person in the US again would have the time adjusted by their GMT!
Also if you have an audit attribute which is set to CURRENT_TIMESTAMP so you know when the appointment was added it would be stored in the db as 9am, as the server time is used for the CURRENT_TIMESTAMP and so is not adjusted. But then that time as its a timestamp is displayed in his local time so it ends up being correct.
I think its totally unusable as it stands and don't understand why it works this way. I would have thought that you just change the CURRENT Timestamp AND DATE functions so that a user can work with them in their local time zone. Also any processes that use these CURRENT date time functions would work correctly if for example you were trying to display late actions or to do lists etc. If you have a query displayed as a calendar the current day which is highlighted is the day determined by your server.
But I've been hoping that support would come forth with why they did not change the CURRENT functions to reflect local time zones and decided instead to display/adjust ALL timestamp attributes in the local time.
I've misunderstood things before so this would not be the first time if I indeed have it wrong. But to me as it stands it is not only unusable it's wrong.
Cheers Rod
-
aware_support
- Posts: 7525
- Joined: Sun Apr 24, 2005 12:36 am
- Contact:
The way timezones work are explained in one of our posts above.
In the database the time is always stored in the timezone of the SERVER.
To the user the time is DISPLAYED in the timezone of the user (if he is registered to have a different timezone). So the time is converted from the timezone of the server to the timezone of the user before the time is displayed to the use and it is converted back from the timezone of the user to the timezone of the server when the user saves a form.
If it doesn't work like this, then there is a bug. If you are sure there is a bug please send the BSV with the steps to reproduce it.
In the database the time is always stored in the timezone of the SERVER.
To the user the time is DISPLAYED in the timezone of the user (if he is registered to have a different timezone). So the time is converted from the timezone of the server to the timezone of the user before the time is displayed to the use and it is converted back from the timezone of the user to the timezone of the server when the user saves a form.
If it doesn't work like this, then there is a bug. If you are sure there is a bug please send the BSV with the steps to reproduce it.
Aware IM Support Team
Thanks Support for confirming that the one appointment therefore will be displayed differently for each user in a different time zone.
This to me is not how such functionality should operate. My wish list would be to have the CURRENT date and time functions behave according to local time zones and not do what you are currently doing.
We will just have to agree to disagree as to the value of this functionality as it currently stands.
Cheers Rod
This to me is not how such functionality should operate. My wish list would be to have the CURRENT date and time functions behave according to local time zones and not do what you are currently doing.
We will just have to agree to disagree as to the value of this functionality as it currently stands.
Cheers Rod
And for Support .... Thinking about it logically, all that needs to happen is for any CURRENT_xxxx functions to be converted and displayed in local time, and then stored in the db as local time. Any other requirements can be handled by us - us the developers.
If there is any support for this view, please post
If there is any support for this view, please post
Rocketman
V8.7 Developer Edition. Server 2016 Standard edition. MySql 5.5
V8.7 Developer Edition. Server 2016 Standard edition. MySql 5.5
Yes I agree RocketMan.
My suggestion which is a slight addition to yours, would be for Support to:
Introduce an option (check box) for this attribute called LocalTZDisplay or similar which has three options:
OFF - TimeZone operates as it does now for those who find it useful.
ON - Causes CURRENT_xxx date and time functions to adjust automatically to the local time zone for the logged in user and causes the current date (Today) on calendar displays to adjust to the local time zone.
BOTH - Both of the above.
Support can you give us some idea of the likelihood of fixing this issue in the near future due to developers such as us who are trying to market applications across the globe based on hosted servers which may be located anywhere.
Cheers Rod
My suggestion which is a slight addition to yours, would be for Support to:
Introduce an option (check box) for this attribute called LocalTZDisplay or similar which has three options:
OFF - TimeZone operates as it does now for those who find it useful.
ON - Causes CURRENT_xxx date and time functions to adjust automatically to the local time zone for the logged in user and causes the current date (Today) on calendar displays to adjust to the local time zone.
BOTH - Both of the above.
Support can you give us some idea of the likelihood of fixing this issue in the near future due to developers such as us who are trying to market applications across the globe based on hosted servers which may be located anywhere.
Cheers Rod