tfertil
Posts: 43
|
| Posted: 11/17/2010, 6:30 PM |
|
I'm writing my first CCS application, and it will be hosted in a server in a place that is 8 time zones away (so my time = server time - 8 hours).
Different users will be at different time zones.
When a user insert or modify a date/time field in any record... how can I adjust this value to a "standard" time (say GMT+0) and the adjust back to the time zone of every user when the value is displayed.
So, if a user stores a date/time value in London (GMT+0), and the value is showed at my place (GMT-6), I need to see not the value for the London user but the value MINUS six hours.
I'm thinking I can get the time zone of the client station and adjust the values before updating the Database, and then adjust it back when retrieved...
Any suggestion?
|
 |
 |
JimmyCrackedCorn
Posts: 583
|
| Posted: 11/17/2010, 10:22 PM |
|
for the server you can easily build in the proper offset and apply it as needed. But for the users I think you will need to ask them their timezone and perhaps even ask about daylight savings for their area. However, once you know everyone's timezone and adjustment you can (should?) convert everything in your database to a standard like GMT+0. And have another field with the + or -.
I'm curious to see if anyone has some more clever ideas as I have not yet implemented such a system but I may need to soon! Good luck.
_________________
Walter Kempees...you are dearly missed. |
|
|
|
tfertil
Posts: 43
|
| Posted: 11/18/2010, 3:31 AM |
|
Thanks, JimmyCrackedCorn.
I found this Javascript function to obtain the number of hours plus or minus GMT the client's browser is in:
function get_time_zone_offset( ) {
var current_date = new Date( );
var gmt_offset = current_date.getTimezoneOffset( ) / 60;
return gmt_offset;
}
So in my login page I'm getting this value and store it in a session variable.
Then, all pages that have a date in it must be checked so the offset is substracted from the date values BEFORE saving it, and added to the database values BEFORE showing it.
I'm working on that... thanks again!
|
|
|
|
tfertil
Posts: 43
|
| Posted: 11/18/2010, 3:38 AM |
|
To JimmyCrackedCorn:
Thanks for reminding me that I must consider DST.
I found an excellent javascript and article about detecting DST here:
http://www.onlineaspect.com/2007/06/08/auto-detect-a-ti...ith-javascript/
Regards!
|
|
|
|
datadoit
|
| Posted: 11/18/2010, 5:58 AM |
|
The javascript method relies upon the end user being 'honest' about
their time setting. I'll run this by our auditor, but I don't think
that'll fly per SAS70 requirements. All transactions are recorded with
the unix timestamp for rollback (non-db) purposes. That shouldn't ever
change. At least record the server transaction time, then define other
fields for end-user transaction time. In our case, our logs have a
timestamp field, along with an IP field. We could technically decipher
what the timezone was for the user based on that information.
For -display- purposes, you could use the honor system by having a
timezone setting per user as JCC suggested, then adjust the offset from
the web server's timezone. But what if the user is EDT, but is
traveling and sitting in a hotel room in PDT? Then the true, accurate
-display- of when that user really made the update will be off.
The way I see it, geocoding is the most accurate way to approach this.
The article referenced was written almost four years ago, before the
days of Google API's. There's now a Google Geocoding service available
and it's free! :)
http://code.google.com/apis/maps/documentation/geocoding/
|
|
|
|
tfertil
Posts: 43
|
| Posted: 11/18/2010, 6:17 AM |
|
Thanks, datadoit.
In this case, the application will be used from various locations around the world, but the users will not be travelling. What we need to do is to display, for every user, the "relative" time a transaction was recorded.
So, if someone enters a new transaction in London, and someone here displays the transaction(we are at Costa Rica, our time zone corresponds to CST but we don't have CST), we must show the time it was at Costa Rica when the transaction enters.
It's for coordination purposes and we think we don't have any security issues: if a user has an incorrect time setting in his PC (either accidentaly or intencionally) he will see incorrect transaction times from other users... but this is not criticall to our application, just inconvinient.
But thanks for your suggestions, we're including station IP in our transactions, and I'm looking a way to record server time.
Regards,
|
|
|
|
|
