I have a system that is a global application, it can be used via a browser or via a notes client The system stores lots of dates to track SLA's and the SLA's themselves are computed based on the day of the week and the time of day. Normally storing dates is fine, you use a date/time field and leave notes to handle the display. Unfortunately the SLA issue here causes me a problem.
So here is where it get's complicated, all the dates/times need to be in CET (Amsterdam) no matter where they are set.
- The server is in UK running GMT
- Users from the web will use local time on Client machine which could be any time zone but dates can potentially be calculated in WQS agent on server
- Administrators can be anywhere but will use a Notes Client
- Reporting must be in CET (Amsterdam)
Now I thought I had something working until I turned my local machines clock forward to April, which of course is GMT+1. Now my CET dates/times are still showing GMT +1 and not taking DST into account. I guess I need to know if the date/time in Amsterdam is DST even if the machine running the code is in New York for example.
So currently my codwould show 01/01/2010 19:00 GMT as 01/01/2010 20:00 CET but 01/04/2010 1900 GMT+1 shows as 01/04/2010 CET as DST is not being taken into account.
I have to admit this is driving me nuts!
So any advice? Ideas?
Posts
Without seeing the whole picture it is difficult to understand the variables here. Timezones are a minefield because there is no globally applicable DST rule and this is why the Notes timezone fields all store the rules for the timezone a datetime applies to.
ReplyDeleteeg. For London:
Z=0$DO=1$DL=3 -1 1 10 -1 1$ZX=35$ZN=GMT
where:
Z=GMT offset in hours
D0=Daylight Time Obervance (1=True, 0=False)
DL=DST rule for relative timezone (startmonth startweek startday endmonth end week endday)
ZX=Timezone index/offset specific to operating systems
ZN=Timezone text description
In the above example, DL=3 -1 1 10 -1 1, which means DST starts on the Sunday of the last week of March and that DST ends on the Sunday of the last week of October.
I think I would probably store the rule for Amsterdam somewhere and in the same format as a Notes timezone field and that I would use it to determine if DST is applying in Amsterdam then adjust the London time as appropriate after first taking in to account whether or not the London time is DST or not.
I'd probably store the London datetime AND timezone in addition to the adjusted Amsterdam datetime AND timezone so that I could troubleshoot any issues etc.
Hi Ian, thanks for replying. I had sort of done what you suggested already. What I did was create a dummy form with a timezone field. Created a document and selected Amsterdam from drop down. Saved it then from the document properties I copied the TZ string which gave me:
ReplyDelete"Z=-1$DO=1$DL=3 -1 1 10 -1 1$ZX=88$ZN=W. Europe";
I then created a test form with 2 dates, The first, SubmitDate, using @now to get current date/time and the second with the following formula:
tz := "Z=-1$DO=1$DL=3 -1 1 10 -1 1$ZX=88$ZN=W. Europe";
@TextToTime(@TimeToTextInZone( SubmitDate ; tz ))
Now this gives me the right date/time value, but the timezone still shows as whatever the current machines timezone is, in this case GDT as I have set my machine forward to April 2010 and I am in UK.
So what your post has helped me see is that I just need to parse the DL attribute to get the actual DST start and End dates and I can work out if the timezone for Amsterdam should be CET of CEST... I think!
I did wonder if the DL attribute might be a piece of the jigsaw.
ReplyDeleteIf you are still having issues I'm wondering if you are using @Now([ServerTime]) to force the app to use the time on the server.
Good luck!
I am also struggling with a similar problem. Mine comes mainly from the timezones that have non-integer GMT offsets (Venezuela, Adelaide, India etc). The issues are that @GetCurrentTimezone can return something more complex (like "Z=3004$DO=0$ZX=87$ZN=Venezuela"). There is another function (@TimeZoneToText) that's supposed to give you back something more usable - like (GMT-04:30) Caracas) but it is very unreliable. If you have anything in the input text that it doesn't like, then it returns the OS time settings.
ReplyDeleteIf you want to talk about this and related issues, try hk611x@att.com