One of possible requirements to handle date/time in distributed client/server systems can be using of single server-based time zone, when all environment executed with the same time shift from UTC.
On server side it's quite transparent - as usually we have control over OS and command-line there, e.g. can specify time-zone on OS or process level for Web server, DB, network, data storage and other resources, so they are not affected by time and localization issues and work seamlessly.
But on client side it can be a bit weird. In "read-only" application with data flow from server-to-client it can be achieved by passing date or time as formatted string in form to be shown on UI, so it's again controlled on server side. Most applications usually run in "read-write" mode, and exist upstream channel from client-to-server. The same approach can be used - client enter date or time in string format, send to server where it will be processed and parse using server locale. In real RIA application operating large datasets and DTOs with hundreds fields it can be problem to implement unfortunately.
Some client/server systems transfers date in numeric UTC format, so theoretically server can shift date value by merging server timezone and client timezone, but in practice it's hard to achieve - client and server code should always know each other and to be in sync. But anyway it's possible to fix this problem in uniform way as described in "OpenAMF/BlazeDS" section below.
It's possible that client machine is not connected to server at all, but you need to use in communications, messengers, e-mails etc NY time independing time zone client computer is bound to. Some tools like AutoHotkey can be installed on client PC to script and automate common tasks.
Below listed AutoHotkey script sample to paste NY time on client side using Alt+T keystrokes. Idea is first to somehow obtain UTC time (in AutoHotkey this is a bit tricky), and then calculate EST UTC-5 time. Just install utility and create file say under "C:\Documents and Settings\{USER}\Documents\AutoHotkey.ahk":
!t::
^Ins::
;# Calculate time zone shift
DT_UTC := A_Now
EnvSub, DT_UTC, %A_NowUTC%, minutes
;# MsgBox, Local delta time from UTC = %DT_UTC% minutes.
;# Calculate real UTC time
T_UTC := %A_NowUTC%
T_UTC += -DT_UTC, minutes
;# Calculate time in necessary time zone
T_NY := T_UTC
T_NY += -5, hours
;# Print text
FormatTime, TS, %T_NY%, MM/dd/yy HH:mm
Send,{space}%TS% - now in NY, thanks.
return
Sample output for Alt+T, prints NY time rather than local Kyiv one:
Flex and AMF is not well popular as today, due to known reasons, but idea used there to implement server-based timezone can be applied to other similar system with this design and problems. AMF protocol passes date objects in numeric format, so in server-to-client direction server first convert date to number, number passed over communication channel and Flash client deserialize value to valid script Date object but in client locale. So if server is in NY region but client from LA uses application, most likely all dates will be shifted day before on screen and reports. To fix this issue was created interceptors on both server and client sides performing date fix work:
For date in server-to-client direction:
1) Before sending date to client, shift it to UTC time (add -Time Zone offest), e.g. for NY time add 5 hours.
2) Send to client.
3) On client side in script shift date to UTC (add -Time Zone offest), e.g. for Singapore substract 8 hours.
For date in client-to-server direction:
1) Before sending date to server, shift it against to UTC (add +Time Zone offest), e.g. for Singapore add 8 hours.
2) Send to server.
3) On server side, shift it against to UTC (add +Time Zone offest), e.g. for NY substract 8 hours.