I NEED GetDaylightChanges
.Net has a TimeZone info for GetDaylightChanges. I can't find it in Silverlight. I hope it is somewhere that I can't find and NOT that someone decided not to publish the information that it obviously has.
I need to tell a server in a different timezone when the timezone where the Silverlight app is being run what datetimes are daylight savings time. The SL app is just preparing information for a scheduler that runs on the server. The server needs to know how to adjust scheduled times from multiple clients run in multiple timezones.
It isn't sufficient to know if the SL CURRENTLY is in DST which seems to be all that SL is willing to give up.
Please tell me there is an easy way to get this information in SL.
.Net has a TimeZone info for GetDaylightChanges. I can't find it in Silverlight. I hope it is somewhere that I can't find and NOT that someone decided not to publish the information that it obviously has.
I need to tell a server in a different timezone when the timezone where the Silverlight app is being run what datetimes are daylight savings time. The SL app is just preparing information for a scheduler that runs on the server. The server needs to know how to adjust scheduled times from multiple clients run in multiple timezones.
It isn't sufficient to know if the SL CURRENTLY is in DST which seems to be all that SL is willing to give up.
Please tell me there is an easy way to get this information in SL.
Answers & Comments...
Answer: 1
Hi, it seems that GetDaylightChanges is not supported in Silverlight so far, but I think you can build a WCF web service for you Silverlight to adjust scheduled times from multiple clients run in multiple timezones.
Here is a link that may help you: http://pholpar.wordpress.com/2011/01/29/how-to-get-the-assembly-version-number-from-the-build-date-and-vice-versa/
Answer: 2
Your link is missing and I don't see how a web service could help. The server may be running on an entirely different time zone. What I did was write a little wpf app that the user can use SL to download and that app puts all the information in the clipboard. Then they can use SL's clipboard to read it in.
Multi-step solution and I don't like it, but it looks like it can't be done just in SL.
Would be really interesting to see that link.
Answer: 3
Have you tried bypassing the timezone+DST stuff and just use UTC? Sounds like it would be a lot simpler in this case.
Answer: 4
UTC is what was the source of problems in the first place. I started off simply. I had local times in my app. I stored it on the server. That worked fine on a local server. Now the server is in a different time zone. So when the client says start the app at 9am, the server won't see that time until 10am.
So then I converted into and out of UTCs from the local client. Now when the client says 9am, the server is told the UTC time. So the server will schedule at a time that matches the clients 9am request. And this works for all clients and all locations of servers.
There is at least one problem. One of the schedule patterns is to schedule on a specific day/days. So my customer said, schedule one at 9PM. The UTC time was 1AM of the next day. That part is fine. The schedule is evaluated at the time the client wanted. BUT the UTC time is a different DAY.
So if the client wants it scheduled only on Sundays, at 9:01PM on Saturday, the UTC is 1:01AM Sunday. So the TIME criteria to schedule is correct, but then when I ask the UTC what DAY it is, it says SUNDAY and off goes the job on the CLIENT'S Saturday when he wanted Sunday.
So now I am trying to get the local time information as in the UTC Offset, the Start and End datetime for Daylight Savings Time, and the Delta for the DST (which can be things like 1 hour, but can also be things like 1/2 hour).
So I will then convert the UTC back to the original requester's local time so that I can get the DAY in local time.
So, bottom line, I started out with local time only, switched to UTC on the server with translation in and out on the client, and that broke my scheduler, and I need the local time zone information.
Hence my need for GetDaylightChanges.
My solution is to provide a downloadable WPF app that gets the DST information and puts it in the clipboard. Then the SL app can copy the clipboard and persist that info to the IsolatedStorage. From then on, it can be stored with the schedule request so the corrections can be made.
Answer: 5
Answer: 6
Hi,
Does it help if the client can choose (or let server automatically detect by checking client IP, not quite accurate though) his timezone information and store to client profile in server? Then server is able to retrieve client timezone information for the request and do what you need.
Answer: 7
It would help if the GetDaylightChanges were supported in SL. :-)
I don't even know how to find the DST from an IP, but if it isn't accurate, then I can't use it.
I am currently checking if they have the DST information stored in isolated storage. If it isn't, my app starts on a page that has 2 buttons. First button downloads a wpf program if the don't have it already. Then they have to run the program. The program gets the DST info and copies it to the clipboard. Then the next SL button looks in the clipboard for the information and if it doesn't find it, it complains. If it does find it, it stores it in the isolatedstorage.
Then when a schedule is updated, that information is sent with each scheduled item. Then the server can make the adjustment.
It isn't horrible since it only needs to be done once, but it just seems silly to not be able to get more information in SL. If it can determine whether or not it is IN DST, then it has to know the start and end times for DST. And it just hasn't exposed them which is annoying.
Answer: 8
Hi,
I just checked the time zone related libraries. Is TimeZoneInfo.Local.IsDaylihtSavingTime() what you need? For each date time the SL client is able to know whether it is in DST. I think it's sufficient in your case?
Answer: 9
No, it isn't sufficient. The SERVER needs to know what time it is on the client wherever in the world the client is.
So the server needs to know the start and end times for DST on the client machine and the UTC offset and the DST Delta.
As my original post said, this is for a scheduler server app. It wakes up at an interval and needs to decide if it is time to run the job. And the scheduled time is specified by the client and given to the server in UTC. But it also can have criteria like, it has to run after 9 PM EST AND it has to be on Sunday. So if the only thing the server knows is the UTC, that criteria is met when the server is at 1AM.
So if it is Saturday on the client and the server determines it is time to schedule the job because it is after 1AM in UTC, the server is on SUNDAY and would schedule the job. But it is still Saturday on the client.
So I need all the other information to decide what day it is on the client.
WITH the time zone information from the client, the server can adjust its UTC to find out what time it really is on the client and what day it is on the client (rather than the server).
Answer: 10
Hi,
>So I need all the other information to decide what day it is on the client.
Then I think you can use a dropdownlist to let customer choose his timezone and store in client profile database that can be retrieved by service later. Your current workaround that uses additonal wpf application to get this data is a little overwhelming in my opinion.
Answer: 11
I totally agree that the WPF app is a kludge, but it was all I could come up with since SL doesn't provide all the information.
There is no reason to ask the user to CHOOSE their time zone. We KNOW the client time zone from DateTime.CurrentTimeZone. But what would you DO with that information? And we know that CURRENTLY they may be in DST, but what can the server do with that information to find out if, at the time the server is making the decision, whether to schedule? How would it know if the client is CURRENTLY in DST?
Answer: 12
Why not try a different approach - only have one global time used by the server, and commicate the difference (i.e. hours & minutes) between the schedule start time and current time on the server - pass this to the clent and the schedule start would be shown in their local time i.e their current time plus the difference.
Answer: 13
Only one time IS allowed by the server, UTC. And the server can't adjust the UTC time unless it knows if the client is currently in DST. And the server can't ask the client for the difference if the client isn't there during scheduling. I already am converting local times into UTC for the server when creating the schedule and converting back from UTC to local when coming down to the user for displaying current schedules.
So at the time of the scheduled job, the client won't be there to tell the server what time it is locally. The server will have to have all the information to figure out what time the UTC time is locally. Including the DST delta. But I don't see anything in any objects that allow me to convert to local time unless it is EXECUTING on the local machine.
And I don't see a way to create a time zone object, set the time zone standard name and daylight name and a UTC datetime value and have it return the local time in the server's time zone.
Answer: 14
OK I see what you are saying now - the server needs to know what the local time is - not just as too when to run the sceduled job, but also as it will affect the data.
Seems to me different time zones will always leads to problems as to what time is actually being used.
Answer: 15
The idea is that the person who does the scheduling knows what time he wants IN HIS TIME. We just need to make sure the server honors that and we can't do that unless we know all about that person's timezone including the DST datetime ranges and the delta. And those last things aren't provided by the SL api for TimeZone.
I can get it from the WPF app, and I've made that work. But I wish the WPF part weren't needed JUST to get that information.
Answer: 16
Hi,
If the server can get the timezone information ( a string to indicate the time zone), the server should be able to know DST of that timezone. There're some articles available on the internet shows how to do that. Such as:
http://codingsense.wordpress.com/2010/02/03/getdaylightchanges-with-timezoneinfo/
As to whether to let users choose or let application automatically get the timezone, it depends. But I prefer letting users choose that. It can be configured at the first app launch and users are able to modify later if they want to. In my opinon the users should be able to switch among different timezones they configured. Giving more flexibilities to users should be a better approach.
Answer: 17
I think that last message contained stuff I could use (now that I already have all the other stuff coded). So maybe I will switch to that. I didn't notice those methods when I poking around before.
thanks.
Answer: 18
So I finally used a service to get the list of time zone names available on the service. The SL app shows that in a combobox and defaults to the local user time zone. Then I store that time zone with their data. Then everything is done by converting the time on the server to the local time for the record the user made. Then the times properly compare.
So the user in Idaho can schedule a job that runs at 9pm in Abu Dhabi time and another that runs at 9pm Seoul time. And the will be scheduled by a box in New York that runs in that time, but knows when it is the right time in the other zones.
Answer: 1
Hi, it seems that GetDaylightChanges is not supported in Silverlight so far, but I think you can build a WCF web service for you Silverlight to adjust scheduled times from multiple clients run in multiple timezones.
Here is a link that may help you: http://pholpar.wordpress.com/2011/01/29/how-to-get-the-assembly-version-number-from-the-build-date-and-vice-versa/
Answer: 2
Your link is missing and I don't see how a web service could help. The server may be running on an entirely different time zone. What I did was write a little wpf app that the user can use SL to download and that app puts all the information in the clipboard. Then they can use SL's clipboard to read it in.
Multi-step solution and I don't like it, but it looks like it can't be done just in SL.
Would be really interesting to see that link.
Answer: 3
Have you tried bypassing the timezone+DST stuff and just use UTC? Sounds like it would be a lot simpler in this case.
Answer: 4
UTC is what was the source of problems in the first place. I started off simply. I had local times in my app. I stored it on the server. That worked fine on a local server. Now the server is in a different time zone. So when the client says start the app at 9am, the server won't see that time until 10am.
So then I converted into and out of UTCs from the local client. Now when the client says 9am, the server is told the UTC time. So the server will schedule at a time that matches the clients 9am request. And this works for all clients and all locations of servers.
There is at least one problem. One of the schedule patterns is to schedule on a specific day/days. So my customer said, schedule one at 9PM. The UTC time was 1AM of the next day. That part is fine. The schedule is evaluated at the time the client wanted. BUT the UTC time is a different DAY.
So if the client wants it scheduled only on Sundays, at 9:01PM on Saturday, the UTC is 1:01AM Sunday. So the TIME criteria to schedule is correct, but then when I ask the UTC what DAY it is, it says SUNDAY and off goes the job on the CLIENT'S Saturday when he wanted Sunday.
So now I am trying to get the local time information as in the UTC Offset, the Start and End datetime for Daylight Savings Time, and the Delta for the DST (which can be things like 1 hour, but can also be things like 1/2 hour).
So I will then convert the UTC back to the original requester's local time so that I can get the DAY in local time.
So, bottom line, I started out with local time only, switched to UTC on the server with translation in and out on the client, and that broke my scheduler, and I need the local time zone information.
Hence my need for GetDaylightChanges.
My solution is to provide a downloadable WPF app that gets the DST information and puts it in the clipboard. Then the SL app can copy the clipboard and persist that info to the IsolatedStorage. From then on, it can be stored with the schedule request so the corrections can be made.
Answer: 5
That link would seem to have nothing to do with time.
mmjj
Hi, it seems that GetDaylightChanges is not supported in Silverlight so far, but I think you can build a WCF web service for you Silverlight to adjust scheduled times from multiple clients run in multiple timezones.
Here is a link that may help you: http://pholpar.wordpress.com/2011/01/29/how-to-get-the-assembly-version-number-from-the-build-date-and-vice-versa/
Answer: 6
Hi,
Does it help if the client can choose (or let server automatically detect by checking client IP, not quite accurate though) his timezone information and store to client profile in server? Then server is able to retrieve client timezone information for the request and do what you need.
Answer: 7
It would help if the GetDaylightChanges were supported in SL. :-)
I don't even know how to find the DST from an IP, but if it isn't accurate, then I can't use it.
I am currently checking if they have the DST information stored in isolated storage. If it isn't, my app starts on a page that has 2 buttons. First button downloads a wpf program if the don't have it already. Then they have to run the program. The program gets the DST info and copies it to the clipboard. Then the next SL button looks in the clipboard for the information and if it doesn't find it, it complains. If it does find it, it stores it in the isolatedstorage.
Then when a schedule is updated, that information is sent with each scheduled item. Then the server can make the adjustment.
It isn't horrible since it only needs to be done once, but it just seems silly to not be able to get more information in SL. If it can determine whether or not it is IN DST, then it has to know the start and end times for DST. And it just hasn't exposed them which is annoying.
Answer: 8
Hi,
I just checked the time zone related libraries. Is TimeZoneInfo.Local.IsDaylihtSavingTime() what you need? For each date time the SL client is able to know whether it is in DST. I think it's sufficient in your case?
Answer: 9
No, it isn't sufficient. The SERVER needs to know what time it is on the client wherever in the world the client is.
So the server needs to know the start and end times for DST on the client machine and the UTC offset and the DST Delta.
As my original post said, this is for a scheduler server app. It wakes up at an interval and needs to decide if it is time to run the job. And the scheduled time is specified by the client and given to the server in UTC. But it also can have criteria like, it has to run after 9 PM EST AND it has to be on Sunday. So if the only thing the server knows is the UTC, that criteria is met when the server is at 1AM.
So if it is Saturday on the client and the server determines it is time to schedule the job because it is after 1AM in UTC, the server is on SUNDAY and would schedule the job. But it is still Saturday on the client.
So I need all the other information to decide what day it is on the client.
WITH the time zone information from the client, the server can adjust its UTC to find out what time it really is on the client and what day it is on the client (rather than the server).
Answer: 10
Hi,
>So I need all the other information to decide what day it is on the client.
Then I think you can use a dropdownlist to let customer choose his timezone and store in client profile database that can be retrieved by service later. Your current workaround that uses additonal wpf application to get this data is a little overwhelming in my opinion.
Answer: 11
I totally agree that the WPF app is a kludge, but it was all I could come up with since SL doesn't provide all the information.
There is no reason to ask the user to CHOOSE their time zone. We KNOW the client time zone from DateTime.CurrentTimeZone. But what would you DO with that information? And we know that CURRENTLY they may be in DST, but what can the server do with that information to find out if, at the time the server is making the decision, whether to schedule? How would it know if the client is CURRENTLY in DST?
Answer: 12
Why not try a different approach - only have one global time used by the server, and commicate the difference (i.e. hours & minutes) between the schedule start time and current time on the server - pass this to the clent and the schedule start would be shown in their local time i.e their current time plus the difference.
Answer: 13
Only one time IS allowed by the server, UTC. And the server can't adjust the UTC time unless it knows if the client is currently in DST. And the server can't ask the client for the difference if the client isn't there during scheduling. I already am converting local times into UTC for the server when creating the schedule and converting back from UTC to local when coming down to the user for displaying current schedules.
So at the time of the scheduled job, the client won't be there to tell the server what time it is locally. The server will have to have all the information to figure out what time the UTC time is locally. Including the DST delta. But I don't see anything in any objects that allow me to convert to local time unless it is EXECUTING on the local machine.
And I don't see a way to create a time zone object, set the time zone standard name and daylight name and a UTC datetime value and have it return the local time in the server's time zone.
Answer: 14
OK I see what you are saying now - the server needs to know what the local time is - not just as too when to run the sceduled job, but also as it will affect the data.
Seems to me different time zones will always leads to problems as to what time is actually being used.
Answer: 15
The idea is that the person who does the scheduling knows what time he wants IN HIS TIME. We just need to make sure the server honors that and we can't do that unless we know all about that person's timezone including the DST datetime ranges and the delta. And those last things aren't provided by the SL api for TimeZone.
I can get it from the WPF app, and I've made that work. But I wish the WPF part weren't needed JUST to get that information.
Answer: 16
Hi,
If the server can get the timezone information ( a string to indicate the time zone), the server should be able to know DST of that timezone. There're some articles available on the internet shows how to do that. Such as:
http://codingsense.wordpress.com/2010/02/03/getdaylightchanges-with-timezoneinfo/
As to whether to let users choose or let application automatically get the timezone, it depends. But I prefer letting users choose that. It can be configured at the first app launch and users are able to modify later if they want to. In my opinon the users should be able to switch among different timezones they configured. Giving more flexibilities to users should be a better approach.
Answer: 17
I think that last message contained stuff I could use (now that I already have all the other stuff coded). So maybe I will switch to that. I didn't notice those methods when I poking around before.
thanks.
Answer: 18
So I finally used a service to get the list of time zone names available on the service. The SL app shows that in a combobox and defaults to the local user time zone. Then I store that time zone with their data. Then everything is done by converting the time on the server to the local time for the record the user made. Then the times properly compare.
So the user in Idaho can schedule a job that runs at 9pm in Abu Dhabi time and another that runs at 9pm Seoul time. And the will be scheduled by a box in New York that runs in that time, but knows when it is the right time in the other zones.
No comments:
Post a Comment
Send us your comment related to the topic mentioned on the blog