GOAL: Use GPS data to get and display the local time.
That's simple to articulate but boy is it a pain to make it happen!
Let's forget all the data receiving and parsing and start from the point where the UTC time is available as a DateTime object from the GPS. In my implementation I created an even called NewCurrentDateTime which passes the current date and time to any subscriber to the event.
Not wanting to overcomplicate things, I decided to hard-code my time zone. Thus, I'm coding for AEST - Australian Eastern Standard Time. But wait! It's daylight savings time. So I'm coding for AEDST - Australian Eastern Daylight Savings Time. Piece of cake! (Yes you northerners, it's summer in Australia! Christmas on the beach and all that.)
Version 1 of my test app used a GMT+11 offset and if the system clock's UTC time differed from the GPS' UTC time by more than 2 seconds, it got reset. The reset configured the time zone as well as the system time. And there it is. And the time is right. Done. Oh, wait ... what happens when daylight savings ends? When is that anyway? A quick dig on the 'Net brings up this.
Version 2 has a little function that takes a date (now) and returns the fall-forward DateTime for daylight savings and the fall-back DateTime. Cool. So now when setting the time I can automatically apply GMT+10 for standard time and GMT+11 for daylight savings time. The trick now is, how does the microcontroller know when the epoch occurs and actually add or subtract an hour at the stroke of 02:00 standard time on the first Sunday in April and October?
Now I could set up timers or events or something to make a one-shot change to the clock at the appropriate moment, buy why bother if the system can do it? Surely it can! And so, with some digging, I found TimeServiceSettings.AutoDayLightSavings. Fantastic. But how does it know when to make the change? I can tell it when, I've already written the method, but how do I do that? Better yet, wouldn't it be great if the framework had all the world's time zones 'hard coded' complete with rules for fall-back and fall-forward dates and times? You would probably need an enumeration for starters ... ooh, look! This is promising.
But that is where the trail when cold. In the time I had I couldn't find out if AutoDayLightSavings works or how to feed it TimeZoneInformation. Even a Google search came up with bupkis. This is my next thing to do.
In the days since I got to dreaming about the big picture. How do I remove my first assumption about being in New South Wales, Victoria or Tasmania - the only places where AEDST applies? I found I can get time zone and daylight savings information from web services such as this one. Alas, my BikeComputer doesn't have Internet access yet. But when it does, that problem is busted. In the mean time. I'm going to play with AutoDayLightSavings and, failing that, hope to write my own timer/event to do it.
Of course any help is appreciated!
That is all.
That's simple to articulate but boy is it a pain to make it happen!
Let's forget all the data receiving and parsing and start from the point where the UTC time is available as a DateTime object from the GPS. In my implementation I created an even called NewCurrentDateTime which passes the current date and time to any subscriber to the event.
Not wanting to overcomplicate things, I decided to hard-code my time zone. Thus, I'm coding for AEST - Australian Eastern Standard Time. But wait! It's daylight savings time. So I'm coding for AEDST - Australian Eastern Daylight Savings Time. Piece of cake! (Yes you northerners, it's summer in Australia! Christmas on the beach and all that.)
Version 1 of my test app used a GMT+11 offset and if the system clock's UTC time differed from the GPS' UTC time by more than 2 seconds, it got reset. The reset configured the time zone as well as the system time. And there it is. And the time is right. Done. Oh, wait ... what happens when daylight savings ends? When is that anyway? A quick dig on the 'Net brings up this.
Version 2 has a little function that takes a date (now) and returns the fall-forward DateTime for daylight savings and the fall-back DateTime. Cool. So now when setting the time I can automatically apply GMT+10 for standard time and GMT+11 for daylight savings time. The trick now is, how does the microcontroller know when the epoch occurs and actually add or subtract an hour at the stroke of 02:00 standard time on the first Sunday in April and October?
Now I could set up timers or events or something to make a one-shot change to the clock at the appropriate moment, buy why bother if the system can do it? Surely it can! And so, with some digging, I found TimeServiceSettings.AutoDayLightSavings. Fantastic. But how does it know when to make the change? I can tell it when, I've already written the method, but how do I do that? Better yet, wouldn't it be great if the framework had all the world's time zones 'hard coded' complete with rules for fall-back and fall-forward dates and times? You would probably need an enumeration for starters ... ooh, look! This is promising.
But that is where the trail when cold. In the time I had I couldn't find out if AutoDayLightSavings works or how to feed it TimeZoneInformation. Even a Google search came up with bupkis. This is my next thing to do.
In the days since I got to dreaming about the big picture. How do I remove my first assumption about being in New South Wales, Victoria or Tasmania - the only places where AEDST applies? I found I can get time zone and daylight savings information from web services such as this one. Alas, my BikeComputer doesn't have Internet access yet. But when it does, that problem is busted. In the mean time. I'm going to play with AutoDayLightSavings and, failing that, hope to write my own timer/event to do it.
Of course any help is appreciated!
That is all.
Comments
Post a Comment