I have a cross platform app that calculates the time of sunrise and sunset based on latitude and longitude.
It then executes actions at certain times, relative to sunset and sunrise, based on the system clock.
Now, once daylight savings time kicks in I need to add the daylight savings time offset to the calculated time of sunrise and sunset, otherwise my sunrise and sunset actions will be an hour off.
Previously I have used a manual “Daylight Savings Time” checkbox that the user can check that controls if the software should add an extra hour to the time of sunrise and sunset, but naturally users forget to check/un-check that checkbox when the daylight savings time changes (or they simply don’t understand the functionality of the check box).
I have therefore been searching for a simple way to auto-determine if the system is on daylight savings time or not, but I have not yet found any simple way to do this.
How can I tell if a system is on daylight savings time or not, without going through the whole mega complex insanity of coding global time zones myself?
There are places in the world that do not use Daylight saving time. LIke in Africa or south America. You could compare the time for them at the same longitude with the time where you calculate. Then you get the offset automatically.
IF you can assume the users computer is configured correctly
create a new date that is set to Jan 1 of whatever year at noon
at this point assume your NOT on DST (I dont know of any place that has DST in effect on Jan 1 - maybe there is ?)
count forward one day at a time until the DST offset changes from that one - you know what date dst goes into effect
and to find the end date you can then simply count forward day by day until it changes again
and stop counting forward by days until you have run through the year
then you can tell what dates DST changes
I’ve used this to determine what dates DST goes into effect for historical dates (back to about 1960)
Why not use the UTC time as a base time. I use it for almost all my apps. The time would not change during the DST rollover. It just displays different based on the user’s locale settings.
I mean, store and do calculations based on the UTC time. Translate the time according to the user’s settings.
That way you don’t have to deal with adjusting your time by 1 hour.
Of course you know what the UTC time is. But for those that don’t:
UTC is the universal time. Daylight Savings doesn’t affect it. This time is used in aviation, satellite communications, etc… So, when I say 23:00 UTC (24 hour notation) it means 2am CET, or 5pm CST. Of course in winter the time changes, but not for UTC
That’s why it’s good practice to use UTC instead of local time. And according to the user’s settings display whatever timezone time-format they are using
When the sun sets or rises is not a variable. DST is.
So, when you know the longitude and latitude, you can get the sunrise and sunset using an API. Using that, you can use that data.
And using UTC other than the local time, you have less variables to deal with. Like this API does.
And with the new Xojo Framework it is an “Apple and and a little egg” (translation: piece of cake) as we would say it in Holland (I mean, the timezone settings on xojo.core.date)
Its not necessary to make an API call to figure out sunrise / sunset once you have long lat & the current date & know if dst is in effect http://www.esrl.noaa.gov/gmd/grad/solcalc/calcdetails.html
The excel spreadsheet is fun
You can compute a years worth at a crack
This part of this app doesn’t need an api call to do the right thing
[quote=257582:@Norman Palardy]Its not necessary to make an API call to figure out sunrise / sunset once you have long lat & the current date & know if dst is in effect http://www.esrl.noaa.gov/gmd/grad/solcalc/calcdetails.html
The excel spreadsheet is fun
You can compute a years worth at a crack
This part of this app doesn’t need an api call to do the right thing[/quote]
You’re right. The API calculates the values like the formula you just mentioned. Now we just need to fit it into nice method or class to use it in a convenient matter
I started on a class myself. But based on the API. Now I can use the formula you just mentioned to finish it, without any 3rd party API’s
[quote=257582:@Norman Palardy]Its not necessary to make an API call to figure out sunrise / sunset once you have long lat & the current date & know if dst is in effect http://www.esrl.noaa.gov/gmd/grad/solcalc/calcdetails.html
The excel spreadsheet is fun
You can compute a years worth at a crack
This part of this app doesn’t need an api call to do the right thing[/quote]
Correct, an API call is not necessary.
I used the formula on http://users.electromagnetic.net/bu/astro/iyf-calc.php to create a method that returns a “theoretical” sunrise and sunset time for a given date, latitude and longitude.
Interestingly once you start to study and try to understand sunrise and sunset calculations you realise that it too is a rather complex matter with several potentially “correct” answers depending on how you choose to define sunrise and sunset.
Also in the far northern and southern hemisphere there simply is no sunrise or sunset parts of the year (ever heard of the midnight sun), and if your app is performing actions based on sunrise and sunset they will never execute unless your app deal with it in some other way.
If anyone is interested I could create a simple demo project with my sunrise-sunset method and share it online.
For North Hem use Nov 15th as starting point instead of Jan 1st
for South Hem use May 15th
I believe you then have it covered… notice that over 1/2 the countries in the world don’t do DST at all[/quote]
Yes, this would give me the dates when/if DST starts and ends, and by processing that info I would get the answer to my question.
I just have a gut feeling that there is an easier way of doing this than looping through potentially 365 dates, storing 2 dates, and comparing those 2 dates with today, whenever I want to know if the system is on DST or not… maybe Im wrong?
[quote=257620:@Albin Kiland]Interested!
I currently use an API on my Magic Mirror to get rid of that would be nice.[/quote]
Hej Albin.
That is one cool mirror, I have to build me one of those some day.
Hm… Mirror mirror on the wall… do you think it would be possible to ad an interactive camera to the Pi and some face recognition algorithms and graphics stuff so that my wife and daughters could simulate different makeups and hair styles in realtime on the screen mirror? Maybe even for me to grow back my hair and get a decent beard
[quote=257581:@Edwin van den Akker]When the sun sets or rises is not a variable. DST is.
So, when you know the longitude and latitude, you can get the sunrise and sunset using an API. Using that, you can use that data.
And using UTC other than the local time, you have less variables to deal with. Like this API does.
And with the new Xojo Framework it is an “Apple and and a little egg” (translation: piece of cake) as we would say it in Holland (I mean, the timezone settings on xojo.core.date)[/quote]
Would it be possible to somehow, within Xojo, compare UTC time with the local system GMT for a given location to see if there is a DST difference?
