ASTRO_CLOCK vs. TimeManager, sunrise/set
Rich Abel
Junior Member
I'm getting incorrect sunrise and sunset times from the Astro_Clock function. Using TimeManager I get the correct sunrise & sunset times. Both using same timeserver, same latitude & longitude.
Tech support suggests not using Astro_Clock.
I'm curious....anyone else encountered this before?
Thanks
Tech support suggests not using Astro_Clock.
I'm curious....anyone else encountered this before?
Thanks
Comments
-
I've been using i!-TimeManager since it was released, and never even tried ASTRO_CLOCK.
-
The offset is weird.
To use ASTRO_CLOCK, check when sunrise and sunset are supposed to be, then adjust your offset that you pass to ASTRO_CLOCK to make them match. Offset seems to +16 from local time for us out here (PST/PDT). -
Try this thread if your not confused enough already:
http://www.amxforums.com/showthread.php?t=6681&highlight=astro -
ASTRO_CLOCK
There is nothing wrong with ASTRO_CLOCK. I?ve been using it for years without issue. You?ll have to add an hour if DST is true.I'm getting incorrect sunrise and sunset times from the Astro_Clock function. Using TimeManager I get the correct sunrise & sunset times. Both using same timeserver, same latitude & longitude.
Tech support suggests not using Astro_Clock.
I'm curious....anyone else encountered this before?
Thanks
Are you using the correct value for GMT? For example here in my neck of the woods in the Midwest it?s -6.
Post your code if you want and we?ll figure out the problem.
Nothing weird about it, no need to fudge the numbers. The function works correctly. I never heard of a +16 hour offset, you sure it?s not -8? Although rolling over into the next day will get you to the same place timewise.The offset is weird.
To use ASTRO_CLOCK, check when sunrise and sunset are supposed to be, then adjust your offset that you pass to ASTRO_CLOCK to make them match. Offset seems to +16 from local time for us out here (PST/PDT). -
I agree there is nothing wrong with the ASTRO_CLOCK function but .....
the question then is how do you know when DST is active? CLock Manger only tells you if you have or have not enabled DST not whether it is ACTIVE. -
There's always this: nTimeMngr_DST = CLKMGR_IS_DAYLIGHTSAVINGS_ON() ;
CLKMGR_IS_DAYLIGHTSAVINGS_ON Returns FALSE/0 or TRUE/1. The default setting is FALSE/0.
I would assume the DST rules are built it otherwise what's the purpose of this query? But are the rules universal for all that observe it? Hmmm... -
Hmmm, I guess we have to set these values ourself.
CLKMGR_SET_START_DAYLIGHTSAVINGS_RULE
CLKMGR_SET_END_DAYLIGHTSAVINGS_RULE
CLKMGR_SET_DAYLIGHTSAVINGS_MODE
CLKMGR_SET_DAYLIGHTSAVINGS_OFFSET
I would assume if you set these astro_clock settings it will return the correct time so you won't need to -+ an hour for DST. You could also just create your own DST flag when DST begins and ends and do the math based on your flag. -
Joe Hebert wrote: »Nothing weird about it, no need to fudge the numbers. The function works correctly. I never heard of a +16 hour offset, you sure it?s not -8? Although rolling over into the next day will get you to the same place timewise.
We are -8/-7DST. I tried -8 first. Did not function as expected - hour was way off. I had to apply a 16 hour offset from local time (basically, +8/+9DST) in order to get correct values. Time was set and the proper timezone was selected on the master. -
I just tried San Diego California and it works just fine:We are -8/-7DST. I tried -8 first. Did not function as expected - hour was way off. I had to apply a 16 hour offset from local time (basically, +8/+9DST) in order to get correct values. Time was set and the proper timezone was selected on the master.
Latitude = 32.72
Longitude = -117.16
GMT = -8
Adding an hour for DST and I get:
Sunrise = 06:28
Sunset = 19:11
You must have something else going on that’s not correct. Are you using DOUBLEs for Lat, Long, and GMT? Is your Longitude negative?
The time on the master should have nothing to do with the results. It's just a formula. Obviously the date has to be correct. -
It is used as specified (so yes, doubles are used) - and yes, longitude is negative. After applying the gross offset, the values are correct.Joe Hebert wrote: »You must have something else going on that?s not correct. Are you using DOUBLEs for Lat, Long, and GMT? Is your Longitude negative?
Thinking about it now, no, it shouldn't. I can't describe why I have this problem, but I don't really care much, since it worked in the end.Joe Hebert wrote: »The time on the master should have nothing to do with the results. -
So why do I have to waste time dealing with this, whatever this is......to get what other manufacturer's already have written to get a simple correct time and whether sunset or sunrise has occurred and whether DST is active from my control system? Is it Astro_Clock, i! Time Manager, i! Scheduler, Clock Manager? How about a complete document that clearly shows the steps required and what not to replicate?
What am I missing? Is there a document somewhere I have missed? -
Re: ASTRO_CLOCK, it's documented in help.
Re: other stuff, they have some documentation but I don't use them.
I'll write some sample code with ASTRO_CLOCK() (using clkmgr with an assumed +1h DST offset, although you can pull this from the master too). All you need to do is include this and you'll have working sunrise/sunset./* variables */ define_variable volatile double ss_coords[2] = {0.0, 0.0} // set these to target lat/long volatile double ss_gmt_offset volatile char ss_sunrise[8] volatile char ss_sunset[8] /* start */ define_start // use this function to determine if DST is on or not if (clkmgr_is_daylightsavings_on()) { // startup code when DST is on goes here wait (200) send_string 0, 'DST is active' } else { // startup code when DST is not on goes here wait (200) send_string 0, 'DST is not active' } /* mainline */ define_program wait (600) { astro_clock(ss_coords[2], ss_coords[1], ss_gmt_offset + clkmgr_is_daylightsavings_on(), LDATE, ss_sunrise, ss_sunset) // send_string 0, "'Sunrise is at ', ss_sunrise, '; sunset is at ', ss_sunset" if (left_string(ss_sunrise, 5) == left_string(TIME, 5)) { // code for when sunrise occurs goes here send_string 0, 'SUNRISE OCCURRED' } if (left_string(ss_sunset, 5) == left_string(TIME, 5)) { // code for when sunset occurs goes here send_string 0, 'SUNSET OCCURRED' } }
Set ss_coords and ss_gmt_offset. Every minute, ss_sunrise and ss_sunset will be updated, and instructions will be executed depending on if the current time matches.. Check these by debugging to make sure they're right. I haven't tested it. It should work. Point out issues if you see them, please.
EDIT: fixed obvious bug.
EDIT 2: As indicated by Joe Hebert below, the DST stuff likely doesn't work properly. I'll update this later with an implementation for you, glr-fti. -
I see your problem true.
volatile double ss_gmt_offset
You need to set the GMT value just like you need to set lat and long. Check out the help file. In your case for the west coast it should be -8. Do that and you should be fine. No fudging needed.// use this function to determine if DST is on or not if (clkmgr_is_daylightsavings_on()) {
Unless things have changed I believe that will only tell you if DST is observed or not. It doesn?t tell you if it?s active at the moment which is what Gary (glr-fti) is talking about.
This has been brought up on the forum previously and I sure hope AMX gives us the flag in the future. Or maybe we have it and I just don?t know about it.Re: ASTRO_CLOCK, it's documented in help.
Re: other stuff, they have some documentation but I don't use them.
I'll write some sample code with ASTRO_CLOCK() (using clkmgr with an assumed +1h DST offset, although you can pull this from the master too). All you need to do is include this and you'll have working sunrise/sunset./* variables */ define_variable volatile double ss_coords[2] = {0.0, 0.0} // set these to target lat/long volatile double ss_gmt_offset volatile char ss_sunrise[8] volatile char ss_sunset[8] /* start */ define_start // use this function to determine if DST is on or not if (clkmgr_is_daylightsavings_on()) { // startup code when DST is on goes here wait (200) send_string 0, 'DST is active' } else { // startup code when DST is not on goes here wait (200) send_string 0, 'DST is not active' } /* mainline */ define_program wait (600) { astro_clock(ss_coords[2], ss_coords[1], ss_gmt_offset + clkmgr_is_daylightsavings_on(), LDATE, ss_sunrise, ss_sunset) // send_string 0, "'Sunrise is at ', ss_sunrise, '; sunset is at ', ss_sunset" if (left_string(ss_sunrise, 5) == left_string(TIME, 5)) { // code for when sunrise occurs goes here send_string 0, 'SUNRISE OCCURED' } if (left_string(ss_sunset, 5) == left_string(TIME, 5)) { // code for when sunset occurs goes here send_string 0, 'SUNSET OCCURED' } }
Set ss_coords and ss_gmt_offset. Every minute, ss_sunrise and ss_sunset will be updated, and instructions will be executed depending on if the current time matches.. Check these by debugging to make sure they're right. I haven't tested it. It should work. Point out issues if you see them, please.
EDIT: fixed obvious bug. -
that isn't my "problem" - I wrote this in 5 minutes from bed as a demo for this guy, and even stated below the code that it needs to be set if this code is to be used. A proper offset was used in my production code. Otherwise, how do you think I figured a +16hour offset to local time?Joe Hebert wrote: »I see your problem true.
...(no problem)...
You need to set the GMT value just like you need to set lat and long. Check out the help file. In your case for the west coast it should be -8. Do that and you should be fine. No fudging needed.
I assumed DST would turn on / off - so the switch is to turn observance on, rather than currently being observed on? I didn't test this thoroughly. That's kind of backwards thinking or bad function naming - especially since documentation for clkmgr stuff is pretty bad. It's something I'll look at closer, thanks. (Which means it's trivial but not simple to get DST being observed now, as you now need to calculate based on current rules...sigh.) I'll probably write a function we can all use (clkmgr_is_currently_dst()?)Joe Hebert wrote: »// use this function to determine if DST is on or not if (clkmgr_is_daylightsavings_on()) {Unless things have changed I believe that will only tell you if DST is observed or not. It doesn?t tell you if it?s active at the moment which is what Gary (glr-fti) is talking about. -
true wrote:that isn't my "problem" - I wrote this in 5 minutes from bed as a demo for this guy, and even stated below the code that it needs to be set if this code is to be used.
Easy there big fella, no need to get your feathers ruffled.
I read your comments by the variable declarations and missed the part down below.
The ?proper? offset for the west coast is -8 GMT. It?s easy enough to look up on a time zone map like the one built into Windoze. There is no such thing as +16 GMT. But as I stated before since we?re dealing with a 24 hour clock +16 rolls over into the next day and ends up the same as -8 the next day.true wrote:A proper offset was used in my production code. Otherwise, how do you think I figured a +16hour offset to local time?
If I use your code with the correct offset of -8 GMT then I get the correct value for sunrise and sunset.
ASTRO_CLOCK works fine with the correct values. Nothing weird about it.
Yes, I believe that?s the case. Sucks I know. I hope I?m wrong.true wrote:I assumed DST would turn on / off - so the switch is to turn observance on, rather than currently being observed on?
Peace. -
As I've said a few times now, my offset is +16h from local time, not from GMT. You even quoted me on that. This would be an offset of +8 or +9 passed to the "GMT" parameter for PST or PDT, respectively.Joe Hebert wrote: »The ?proper? offset for the west coast is -8 GMT. It?s easy enough to look up on a time zone map like the one built into Windoze. There is no such thing as +16 GMT.
I get the wrong value unless I pass +8 or +9. Only had to use ASTRO_CLOCK() once so far (had to do it a lot with C restron customers but never had the request until recently with an AMX customer). I tried it on my NI with the same results. I'll probably be hacking away at stuff this weekend so I'll try to figure out where the bug lies.Joe Hebert wrote: »If I use your code with the correct offset of -8 GMT then I get the correct value for sunrise and sunset.
ASTRO_CLOCK works fine with the correct values. Nothing weird about it. -
The function calls for GMT. GMT for the west coast is negative 8. Forget the whole local time thing.As I've said a few times now, my offset is +16h from local time, not from GMT. You even quoted me on that. This would be an offset of +8 or +9 passed to the "GMT" parameter for PST or PDT, respectively.I get the wrong value unless I pass +8 or +9. Only had to use ASTRO_CLOCK() once so far (had to do it a lot with C restron customers but never had the request until recently with an AMX customer). I tried it on my NI with the same results. I'll probably be hacking away at stuff this weekend so I'll try to figure out where the bug lies.
Using your code with the correct value for GMT (-8) I get then correct values for sunrise/sunset for San Diego (ignoring the whole DST thing) as shown below:define_variable _ volatile double ss_coords[2] = {32.72, -117.16} // set these to target lat/long [b]volatile double ss_gmt_offset = -8[/b] volatile char ss_sunrise[8] volatile char ss_sunset[8] /* start */ define_start // use this function to determine if DST is on or not if (clkmgr_is_daylightsavings_on()) { // startup code when DST is on goes here wait (200) send_string 0, 'DST is active' } else { // startup code when DST is not on goes here wait (200) send_string 0, 'DST is not active' } /* mainline */ define_program wait (600) { astro_clock(ss_coords[2], ss_coords[1], ss_gmt_offset + clkmgr_is_daylightsavings_on(), LDATE, ss_sunrise, ss_sunset) send_string 0, "'Sunrise is at ', ss_sunrise, '; sunset is at ', ss_sunset" if (left_string(ss_sunrise, 5) == left_string(TIME, 5)) { // code for when sunrise occurs goes here send_string 0, 'SUNRISE OCCURED' } if (left_string(ss_sunset, 5) == left_string(TIME, 5)) { // code for when sunset occurs goes here send_string 0, 'SUNSET OCCURED' } }
And the output:Line 51 :: Sunrise is at 05:25:00; sunset is at 18:15:00 - 01:45:34
There?s no bug in your code or ASTRO_CLOCK. Where?s the problem? -
GMT
Here is a snapshot showing the value for your GMT true: -
I understand this completely. What I am trying to tell you is that in Pacific Time Zone, I had to pass +8/+9 (which happens to be +16h of local time; it's completely 100% equivalent and means the same exact thing as saying +8/+9GMT) depending on whether daylight savings time is active or not to get the proper values. To clarify, because I'm not sure you're getting it, when I pass -8 in the "GMT" parameter I get values like 22:30 for sunrise. My sun doesn't rise some time just before midnight.Joe Hebert wrote: »The function calls for GMT. GMT for the west coast is negative 8. Forget the whole local time thing.
I don't think you're getting it, and won't really continue - I experienced this offset problem and continue to, others don't, so obviously there is a problem somewhere and as I said, I'll try to figure it out.
I explicitly wrote that I haven't tested this code. Works for you? Great. Maybe my other code has some bug this doesn't, I don't know. I'll test it when I get time but I'm not going to argue with you over semantics (+16h local to PST and +8/+9GMT means the same exact thing! last time I'm writing it!) and try to drive my point yet again when I've written my experience numerous times already.Joe Hebert wrote: »codestuff -
I?ve got no desire to get into a wienie war with you true.I understand this completely. What I am trying to tell you is that in Pacific Time Zone, I had to pass +8/+9 (which happens to be +16h of local time; it's completely 100% equivalent and means the same exact thing as saying +8/+9GMT) depending on whether daylight savings time is active or not to get the proper values. To clarify, because I'm not sure you're getting it, when I pass -8 in the "GMT" parameter I get values like 22:30 for sunrise. My sun doesn't rise some time just before midnight.
One last time. If you use the correct value for GMT as the function calls for which is -8 for pacific time (as the picture above shows) then you?ll get the correct value.
I took the time to test your code and showed you the output. Your code is fine, ASTRO_CLOCK is fine. What else can I do? It?s all there in black and white with a picture.
I don?t care about the local time +/- whatever argument (or parameter as Hedberg might call it.
) It?s irrelevant as it has nothing to do with ASTRO_CLOCK. -
True,
I previously stated that ASTRO_CLOCK works. I know where the documentation is as well. I also know where the documentation is for i!Schedule, i!Time Manager, and Clock Manager. The problem is that none does what is needed in the scenario described. I've been testing i!Time Manager and changing code the last few days, after talking with TS, to see if I could nail this issue. Just when I think I have it something weird happens and changes my offset back to non DST.
As has been pointed out clkmgr_is_daylightsavings_on() only returns whether it has been enabled not whether it is active. Yes we need another that says clkmgr_is_daylightsavings_ACTIVE() then we can all go back to bed. -
True,
I previously stated that ASTRO_CLOCK works. I know where the documentation is as well. I also know where the documentation is for i!Schedule, i!Time Manager, and Clock Manager. The problem is that none does what is needed in the scenario described. I've been testing i!Time Manager and changing code the last few days, after talking with TS, to see if I could nail this issue. Just when I think I have it something weird happens and changes my offset back to non DST.
As has been pointed out clkmgr_is_daylightsavings_on() only returns whether it has been enabled not whether it is active. Yes we need another that says clkmgr_is_daylightsavings_ACTIVE() then we can all go back to bed.
I'll write something later (likely this weekend) that uses clkmgr to check if you are in DST or not. -
astro clock, time manager, clock manager.....
wow, I really got a discussion going on this....sorry to post a message and not be able to respond until now.
Anyway - an update. I'm going to be doing a bunch of time related stuff on an upcoming job so I wanted to bring myself up to date on the various time and astronomical clock functions in Netlinx and the current generation of firmware.
Toward that end, I wrote a program that attempts to use both the TimeManager module and the built-in clock manager and astro_clock routines.
I'm running this code on a NI2000 running master FW v3.50.430.
What is puzzling is that I seem to be getting 4 minutes difference between the Sunrise and Sunset times from Timemanager and astro_clock.
Since I don't have a touch panel handy, my code runs a timeline to generate a timeline event every minute. I call the ASTRO_CLOCK function to get its Sunrise & Sunset for my Seattle location.
I'm running timemanager using the same lat and long values. The system is set to use an external time server. I'm getting a 4 minute difference between the sunrise and sunset times between ASTRO_CLOCK and TimeManager. For example for today 4/13/10 astroclock gives me sunrise of 06:28:00 (which is +4 minutes from the correct time) and timemanager gives me 06:24:00, the correct sunrise time.
As someone else noted, it seems like the numbers ought to be dead on the same. Maybe I have a typo that I'm missing. Here is my source......DEFINE_DEVICE dvDEBUG = 0:0:2 dvMASTER = 0:1:2 vdvTP = 33002:1:2 dvTMTIMESYNC = 0:3:2 vdvTMEVENTS = 33001:1:2 //****************************************************************************** // CONSTANT DEFINITIONS //****************************************************************************** DEFINE_CONSTANT // TIME SERVER CONSTANTS (* TIMESERVER PROTOCOLS *) nProtoNone = 0 nProtoDaytime = 1 nProtoTime = 2 nProtoSNTP = 3 nProtoSNTPBCast = 4 (* TIME SERVER CHANNELS *) nTmSunriseChannel = 1 nTmSunsetChannel = 2 nTmDstChannel = 3 nTmTimeChangeChannel = 4 (* TIME SERVER LEVELS *) nTmGmtEffLevel = 1 nTmGmtLevel = 2 nTmLongLevel = 3 nTmLatLevel = 4 //****************************************************************************** // DATA TYPE DEFINITIONS //****************************************************************************** DEFINE_TYPE //****************************************************************************** // VARIABLE DEFINITIONS //****************************************************************************** DEFINE_VARIABLE // TIME SERVER & TIME RELATED VARIABLES //VOLATILE CHAR cTIMESTRSUNRISE[50] //VOLATILE CHAR cTIMESTRSUNSET[50] //VOLATILE SINTEGER sSUNRISEHOUR //VOLATILE SINTEGER sSUNSETHOUR //VOLATILE SINTEGER sSUNRISEMINUTE //VOLATILE SINTEGER sSUNSETMINUTE VOLATILE CHAR cTMSUNRISE[10] VOLATILE CHAR cTMSUNSET[10] (* TIMEZONE *) VOLATILE CHAR cTMTZNAME[100] VOLATILE CHAR cTMTZDESC[10] VOLATILE DOUBLE dTMTZGMTOFFSET VOLATILE CHAR cTMTZDSTRULES[1000] (* LOCATION *) VOLATILE CHAR cTMLOCNAME[100] VOLATILE DOUBLE dTMLOCLONG VOLATILE DOUBLE dTMLOCLAT (* TIMESERVER *) VOLATILE INTEGER nTMTSPROTOCOL VOLATILE INTEGER nTMTSCHECKTIME VOLATILE CHAR cTMTSSERVER[100] CLKMGR_TIMESERVER_STRUCT TS // TO HOLD CURRENT TIMESERVER INFO CLKMGR_TIMEOFFSET_STRUCT DST_OFFSET VOLATILE CHAR cDST_START_RULE[35] VOLATILE CHAR cDST_END_RULE[35] VOLATILE INTEGER nRESYNCH_PERIOD // MINUTES VOLATILE INTEGER bDST_ON VOLATILE SINTEGER sRET_CODE VOLATILE CHAR cTZ_STRING[25] VOLATILE DOUBLE dHRS_TO_UTC // CURRENT HRS FROM GMT OR UTC CONSTANT LONG lONE_MIN_TL = 1 // TL ID VOLATILE LONG ONE_MIN[] = {60000} // 60,000/1,000 = 60 SEC VOLATILE INTEGER nTL_RET // TIMELINE_CREATE RETURN VALUE VOLATILE DOUBLE dLATITUDE = 47.6350 // NORTH LATITUDE FOR OLIN PLACE VOLATILE DOUBLE dLONGITUDE = -122.3129 // WEST LONGITUDE FOR OLIN PLACE VOLATILE CHAR cSUNRISE[10] VOLATILE CHAR cSUNSET[10] //****************************************************************************** // INCLUDE FILES //****************************************************************************** //****************************************************************************** // LATCHING DEFINITIONS //****************************************************************************** DEFINE_LATCHING //****************************************************************************** // MUTUALLY EXCLUSIVE DEFINITIONS //****************************************************************************** DEFINE_MUTUALLY_EXCLUSIVE //****************************************************************************** // SUBROUTINE AND FUNCTION DEFINITIONS //****************************************************************************** //****************************************************************************** // STARTUP //****************************************************************************** DEFINE_START (***********************************************************) (* STEP 1 - CONFIGURE THE TIMEZONE: *) (***********************************************************) // CONFIGURE TIMEZONE // PARAMETER 1: TIMEZONE NAME. EX: "EASTERN" // PARAMETER 2: TIMEZONE DESCRIPTION. EX: "E%ST" // PARAMETER 3: TIMEZONE GMT OFFSET IN HOURS. EX: -5.0 cTMTZNAME = 'Pacific' cTMTZDESC = 'PD%sT' dTMTZGMTOFFSET = -8.0 // CONFIGURE TIMEZONE RULES // PARAMETER 1: DAYLIGHT SAVINGS STRING. EX: "NONE", "US" OR CUSTOM. // CUSTOM STRING: "MONTH" "DAYDESCRIPTION" "TIME" "OFFSET FROM STD" "DESCRPTION" // "MONTH": MONTH NAME EX: "APR" // "TIME" TIME TO ACTIVATE (HH:MM:SS, 24 HOUR). EX: "02:00:00" // "OFFSET FROM STD" TIME TO OFFSET FROM GMT (HH:MM:SS, 24 HOUR). EX: "01:00:00" // "DESCRIPTION" STRING TO REPLACE "%S" WITH IN TIMEZONE DESCRIPTION. EX: 'D' // "DAYDESCRIPTION" DAY DESCRIPTION. FIXED DATE, LAST DAY OF WEEK OR // FIRST DAY OF WEEK BEFORE/AFTER DATE // FIXED EX: "15" // LAST DAY OF WEEK EX: "LASTSUNDAY" // FIRST DAY OF WEEK BEFORER DATE-EX: "SUN<=24" // FIRST DAY OF WEEK AFTER DATE-EX: "SUN>=1" cTMTZDSTRULES = 'US' (***********************************************************) (* STEP 2 - CONFIGURE PHYSICAL LOCATION: *) (***********************************************************) // CONFIGURE PHYSICAL LOCATION // PARAMETER 1: LOCATION NAME. EX: 'SEATTLE' // PARAMETER 2: LOCATION LONGITUDE. EX: -122.33 (>0 == EAST, < 0 == WEST) // PARAMETER 3: LOCATION LATITUDE. EX: 47.6 (>0 == NORTH, < 0 == SOUTH) cTMLOCNAME = 'Seattle' dTMLOCLONG = -122.3129 dTMLOCLAT = 47.6350 (***********************************************************) (* STEP 3 - CONFIGURE TIME SERVERS: *) (***********************************************************) // CONFIGURE TIME SERVERS // PARAMETER 1: PROTOCOL, 0=DISBALED, 1=DAYTIME(13/UDP, 13/TCP), 2=TIME(37/UDP, 37/TCP), 3=SNTP(123/UDP), 4=SNTP BROADCAST (137/UDP). EX: 2 // PARAMETER 3: DEFAULT SERVER. EX: 'MYTIMESERVER.MYDOMAIN.COM'. LEAVE BLANK TO READ FROM TIME SEVRER FILE (TIME/NIST_SVR.LST) // PARAMETER 2: CHECK TIME INTERVAL IN SECONDS. USE 0 FOR DEFAULT (2 HOURS). EX: 3600 // PARAMETER 4: PREFERED INDEX OF TIMESERVERS IN LIST. EX: 2 // NOTES: IF PARAMETERS 3 IS SUPPLIED, PARAMETER 4 IS IGNORED // IF PARAMATER 3 IS AN EMPTY STRING AND PARAMETER 4 IS 0, A DEFAULT WILL BE PICKED FROM THE LIST IS POSSIBLE // CONSTANTS- // nProtoNone = 0 // nProtoDaytime = 1 // nProtoTime = 2 // nProtoSNTP = 3 // nProtoSNTPBCast = 4 nTMTSPROTOCOL = nProtoSNTP nTMTSCHECKTIME = 0 cTMTSSERVER = '' (***********************************************************) (* ALTERNATE MANUAL TIMEZONE CONFIGURATIONS: *) (***********************************************************) // THESE ARE SHOWN FOR EXAMPLE PURPOSES AND REPRESENT INFORMATION THAT IS NOT GUARANTEED TO BE CORRECT! // HERE IS AN EXMAPLE CONFIGURATION FOR SANTIAGO, CHILE WHICH IS -4 HOURS BEHIND GMT AND OBSERVES DAYLIGHT SAVINGS STARTING // ON THE SATURDAY ON OR AFTER OCTOBER 9TH AT MIDNIGHT (JUMP AHEAD 1 HOUR) AND THE SATURDAY ON OR AFTER THE 9TH OF MARCH AT MIDNIGHT (JUMP BACK 1 HOUR) // AND DESCRIBES THE TIME AS "HH:MM:SS CST" OR "HH:MM:SS CDT" DEPENDING ON DAYLIGHT SAVINGS AND IS LOCATED AT "33S27, 70W40": // // cTMTZNAME = 'Santiago' // cTMTZDESC = 'C%sT' // dTMTZGMTOFFSET = -4.0 // cTMTZDSTRULES = "'Oct Sat>=9 00:00:00 01:00:00 D',$FF,'Mar Sat>=9 00:00:00 00:00:00 S'" // // AND // // cTMLOCNAME = 'Santiago' // dTMLOCLONG = -70.67 // dTMLOCLAT = -33.45 // HERE IS AN EXMAPLE CONFIGURATION FOR SYDNEY, AUSTRALIA WHICH IS +10 HOURS AHEAD OF GMT AND OBSERVES DAYLIGHT SAVINGS STARTING // ON THE LAST SUNDAY IN OCTOBER 2:00 AM (JUMP AHEAD 1 HOUR) AND THE LAST SUNDAY IN MARCH AT 3:00 AM (JUMP BACK 1 HOUR) // AND DESCRIBES THE TIME AS "HH:MM:SS EST" REGARDLESS OF DAYLIGHT SAVINGS AND IS LOCATED AT "33S52, 151E13": // // cTMTZNAME = 'Sydney' // cTMTZDESC = 'EST' // dTMTZGMTOFFSET = 10.0 // cTMTZDSTRULES = "'Oct LastSun 02:00:00 01:00:00 X',$FF,'Mar LastSun 03:00:00 00:00:00 X'" // // AND // // cTMLOCNAME = 'Sydney' // dTMLOCLONG = 151.22 // dTMLOCLAT = -33.86 // HERE IS THE EXAMPLE CONFIGURATION FOR LONDON, ENGLAND WHICH USES GMT AND OBSERVES DAYLIGHT SAVINGS STARTING // ON THE LAST SUNDAY IN MARCH AT 1:00 AM (JUMP AHEAD 1 HOUR) AND THE LAST SUNDAY IN OCTOBER AT 2:00 AM (JUMP BACK 1 HOUR) // AND DESCRIBES THE TIME AS "HH:MM:SS BST" OR "HH:MM:SS GMT" DEPENDING ON DAYLIGHT SAVINGS AND IS LOCATED AT "51N30, 0W10": // // cTMTZNAME = 'London' // cTMTZDESC = '%s' // dTMTZGMTOFFSET = 0.0 // cTMTZDSTRULES = "'Mar LastSun 01:00:00 01:00:00 BST',$FF,'Oct LastSun 02:00:00 00:00:00 GMT'" // // AND // // cTMLOCNAME = 'London' // dTMLOCLONG = -0.16 // dTMLOCLAT = 51.50 // TIMELINES.... nTL_RET = TIMELINE_CREATE(lONE_MIN_TL,ONE_MIN,LENGTH_ARRAY(ONE_MIN),TIMELINE_ABSOLUTE,TIMELINE_REPEAT) SWITCH(nTL_RET) { CASE 0: { SEND_STRING dvDEBUG,"'TL lONE_MIN_TL SUCCESSFULLY STARTED.',$0D" } CASE 1: { SEND_STRING dvDEBUG,"'TIMELINE_CREATE: TIMELINE ID ALREADY IN USE.',$0D" } CASE 2: { SEND_STRING dvDEBUG,"'TIMELINE_CREATE: TIME ARARY NOT ARRAY OF LONGS.',$0D" } CASE 3: { SEND_STRING dvDEBUG,"'TIMELINE_CREATE: LENGTH SPECIFIED GREATER THAN LENGTH OF PASSED TIME ARRAY.',$0D" } CASE 4: { SEND_STRING dvDEBUG,"'TIMELINE_CREATE: OUT OF MEMORY.',$0D" } } // END OF SWITCH ON TIMELINE RETURN DEFINE_MODULE 'i!-TimeManagerMod' mdlTM(vdvTMEVENTS, dvTMTIMESYNC, (* TIMEZONE *) cTMTZNAME, cTMTZDESC, dTMTZGMTOFFSET, cTMTZDSTRULES, (* LOCATION *) cTMLOCNAME, dTMLOCLONG, dTMLOCLAT, (* TIMESERVER *) nTMTSPROTOCOL, nTMTSCHECKTIME, cTMTSSERVER) //****************************************************************************** // EVENTS //****************************************************************************** DEFINE_EVENT TIMELINE_EVENT[lONE_MIN_TL] { cTZ_STRING = CLKMGR_GET_TIMEZONE() SEND_STRING dvDEBUG,"$0A,$0A,$0A,$0A,$0A,$0A,$0A,$0A" // PUT SOME SPACE BETWEEN REPORTS SEND_STRING dvDEBUG,"'CLKMGR CURRENT TIMEZONE IS: ',cTZ_STRING,$0D" IF(FIND_STRING(cTZ_STRING,'UTC',1)) { REMOVE_STRING(cTZ_STRING,'UTC',1) cTZ_STRING = LEFT_STRING(cTZ_STRING,(FIND_STRING(cTZ_STRING,':',1))-1) SEND_STRING dvDEBUG,"'CLKMGR cTZ_STRING= ',cTZ_STRING,$0D" } ELSE SEND_STRING dvDEBUG,"'UTC NOT FOUND IN CLKMGR cTZ_STRING!',$0D" IF(bDST_ON) dHRS_TO_UTC = -7.0 ELSE dHRS_TO_UTC = -8.0 sRET_CODE = ASTRO_CLOCK(dLONGITUDE,dLATITUDE,dHRS_TO_UTC,DATE,cSUNRISE,cSUNSET) SWITCH(sRET_CODE) { CASE 0: { SEND_STRING dvDEBUG,"'ASTRO_CLOCK FUNCTION EXECUTED OK',$0D" } CASE 1: { SEND_STRING dvDEBUG,"'ASTRO_CLOCK LATITUDE ENTRY ERROR',$0D" } CASE 2: { SEND_STRING dvDEBUG,"'ASTRO_CLOCK LONGITUDE ENTRY ERROR',$0D" } CASE 3: { SEND_STRING dvDEBUG,"'ASTRO_CLOCK HOURS ENTRY ERROR',$0D" } CASE 4: { SEND_STRING dvDEBUG,"'ASTRO_CLOCK DATE ENTRY ERROR',$0D" } } // END OF SWITCH ON RETURN CODE IF(CLKMGR_IS_NETWORK_SOURCED()) SEND_STRING dvDEBUG,"'CLOCK MANAGER IS NETWORKED SOURCED',$0D" ELSE SEND_STRING dvDEBUG,"'CLOCK MANAGER IS STAND ALONE',$0D" CLKMGR_GET_ACTIVE_TIMESERVER(TS) CLKMGR_GET_DAYLIGHTSAVINGS_OFFSET(DST_OFFSET) cDST_START_RULE = CLKMGR_GET_START_DAYLIGHTSAVINGS_RULE() cDST_END_RULE = CLKMGR_GET_END_DAYLIGHTSAVINGS_RULE() nRESYNCH_PERIOD = CLKMGR_GET_RESYNC_PERIOD() bDST_ON = CLKMGR_IS_DAYLIGHTSAVINGS_ON() IF(TS.IS_SELECTED) SEND_STRING dvDEBUG,"TS.URL_STRING,', ',TS.LOCATION_STRING,' IS CURRENTLY SELECTED TIMESERVER.',$0D" ELSE SEND_STRING dvDEBUG,"'CLKMGR TIMESERVER IS NOT CURRENTLY SELECTED',$0D" SEND_STRING dvDEBUG,"'CURRENT TIME IS ',TIME,$0D" SEND_STRING dvDEBUG,"'DATE IS ',DATE,$0D" SEND_STRING dvDEBUG,"'SUNRISE TODAY AT ',cSUNRISE,$0D" SEND_STRING dvDEBUG,"'SUNSET TODAY AT ',cSUNSET,$0D" } // END OF TIMELINE_EVENT[lONE_MIN_TL] DATA_EVENT[vdvTMEVENTS] (***********************************************************) (* DATA_EVENT: STRINGS FOR SUNRISE/SUNSET *) (* PURPOSE: PARSE STRINGS FOR SUNRISE AND SUNSET *) (***********************************************************) { STRING: { STACK_VAR CHAR cUPPER[30] STACK_VAR CHAR cTEMP[30] STACK_VAR CHAR cTRASH[30] cUPPER = UPPER_STRING(DATA.TEXT) cTEMP = DATA.TEXT cTRASH = REMOVE_STRING(cTEMP,'-',1) SELECT { ACTIVE (FIND_STRING(cUPPER,'SUNRISE-',1)): { SEND_STRING dvDEBUG,"'i!TimeManager Sunrise Time = ',cTEMP" cTMSUNRISE = cTEMP } ACTIVE (FIND_STRING(cUPPER,'SUNSET-',1)): { SEND_STRING dvDEBUG,"'i!TimeManager Sunset Time = ',cTEMP" cTMSUNSET = cTEMP } ACTIVE (FIND_STRING(cUPPER,'TIMEZONE-',1)): { SEND_STRING dvDEBUG,"'i!TimeManager Timezone = ',cTEMP" } ACTIVE (FIND_STRING(cUPPER,'TIMEDESC-',1)): { SEND_STRING dvDEBUG,"'i!TimeManager Time Description = ',cTEMP" } ACTIVE (FIND_STRING(cUPPER,'LOCATION-',1)): { SEND_STRING dvDEBUG,"'i!TimeManager: Location = ',cTEMP" } } // END OF SELECT-ACTIVE } // END OF STRING DATA_EVENT } // END OF vdvTMEVENTS DATA_EVENT BUTTON_EVENT[vdvTMEVENTS,nTmSunriseChannel] (***********************************************************) (* BUTTON_EVENT: SUNRISE CHANNEL *) (* PURPOSE: CHANNEL IS PUSHED (AND TURNED ON) WHEN *) (* THE SUNRISE OCCURS *) (***********************************************************) { PUSH: { SEND_STRING dvDEBUG,"'i!TimeManager: Sunrise occured at ',TIME" } } BUTTON_EVENT[vdvTMEVENTS,nTmSunsetChannel] (***********************************************************) (* BUTTON_EVENT: SUNSET CHANNEL *) (* PURPOSE: CHANNEL IS PUSHED (AND TURNED ON) WHEN *) (* THE SUNSET OCCURS *) (***********************************************************) { PUSH: { SEND_STRING dvDEBUG,"'i!TimeManager: Sunset occured at ',TIME" } } BUTTON_EVENT[vdvTMEVENTS,nTmDstChannel] (***********************************************************) (* BUTTON_EVENT: DST ACTIVITY CHANNEL *) (* PURPOSE: CHANNEL IS PUSHED (AND TURNED ON) WHEN *) (* THE DST RULES AFFECT A TIME CHANGE WITH *) (* A NON-ZERO TIME OFFSET (DST ACTIVE) *) (* CHANNEL IS RELEASE (AND TURNED OFF) WHEN *) (* THE DST RULES AFFECT A TIME CHANGE WITH *) (* A ZERO TIME OFFSET (DST INACTIVE) *) (***********************************************************) { PUSH: { SEND_STRING dvDEBUG,"'i!TimeManager: DST is now active: ',TIME" } RELEASE: { SEND_STRING dvDEBUG,"'i!TimeManager: DST is now inactive: ',TIME" } } BUTTON_EVENT[vdvTMEVENTS,nTmTimeChangeChannel] (***********************************************************) (* BUTTON_EVENT: TIME CHANGE CHANNEL *) (* PURPOSE: CHANNEL IS PUSHED (AND PULSED) WHEN *) (* THE TIME IS CHANGED BY A COMMUNICATION *) (* WITH A TIME SERVER. *) (***********************************************************) { PUSH: { SEND_STRING dvDEBUG,"'i!TimeManager: Time adjusted by time server. New Time is ',TIME" } } LEVEL_EVENT[vdvTMEVENTS,nTmGmtEffLevel] (***********************************************************) (* LEVEL_EVENT: EFFECTIVE GMT OFFSET *) (* PURPOSE: LEVEL IS SENT WHENEVER THE EFFECTIVE GMT *) (* OFFSET IS CHANGED. THE EFFECTIVE OFFSET *) (* IS THE REAL GMT OFFSET WITH DLS CORRECTION*) (***********************************************************) { SEND_STRING dvDEBUG,"'i!TimeManager: Effective GMT Offset = ',FTOA(LEVEL.VALUE)" } LEVEL_EVENT[vdvTMEVENTS,nTmGmtLevel] (***********************************************************) (* LEVEL_EVENT: GMT OFFSET *) (* PURPOSE: LEVEL IS SENT WHENEVER THE GMT *) (* OFFSET IS CHANGED. *) (***********************************************************) { SEND_STRING dvDEBUG,"'i!TimeManager: GMT Offset = ',FTOA(LEVEL.VALUE)" } LEVEL_EVENT[vdvTMEVENTS,nTmLongLevel] (***********************************************************) (* LEVEL_EVENT: LONGITUDE *) (* PURPOSE: LEVEL IS SENT WHENEVER THE LONGITUDE IS *) (* CHANGED. *) (***********************************************************) { SEND_STRING dvDEBUG,"'i!TimeManager: Longitude = ',FTOA(LEVEL.VALUE)" } LEVEL_EVENT[vdvTMEVENTS,nTmLatLevel] (***********************************************************) (* LEVEL_EVENT: LATITUDE *) (* PURPOSE: LEVEL IS SENT WHENEVER THE LATITUDE IS *) (* CHANGED. *) (***********************************************************) { SEND_STRING dvDEBUG,"'i!TimeManager: Latitude = ',FTOA(LEVEL.VALUE)" } //****************************************************************************** // MAINLINE PROGRAM //****************************************************************************** DEFINE_PROGRAM //****************************************************************************** // END //****************************************************************************** //******************************************************************************
Regardless, I'm going to just use TimeManager and get on with things.....but I am curious where my error lies.
thanks (and take a deep breath),
Rich -
What is puzzling is that I seem to be getting 4 minutes difference between the Sunrise and Sunset times from Timemanager and astro_clock.
ASTRO_CLOCK(dLONGITUDE,dLATITUDE,dHRS_TO_UTC,DATE,cSUNRISE,cSUNSET)
Instead of DATE try LDATE and I believe that should resolve the difference you are seeing.
ASTRO_CLOCK calls for the mm/dd/yyyy format.
DATE returns mm/dd/yy and LDATE returns mm/dd/yyyy
Have fun. -
Bingo!
Thanks Joe! That was it.
Rich -
Sure thing Rich.
Always happy to help.
Long live ASTRO_CLOCK.
-
Since this thread made me realize my switch from !iTimeManager to using the Astro_Clock function left me with errors that I wasn't aware of I decided to change its implimentation and create an dedicated include file for time and date stuff. This is an .axi file not a .axs. I change the file extention just to upload it to the forums.
BTW I only changed to astro_clock because of an error the ZigBee Pro firmware update caused on a job that showed up in my daily log files. To minimize the errors plus being informed that astro_clock runs regardless and since there may be possible negative affects if !iTimemamger is running at the same time I decided to switch to the astro_function since I can control it somewhat and minimize the errors. So I pulled out Timemanager and changed to the astro clock. Of course I didn't pay attention and I didn't impliment it properly which this thread made me aware of.
This is a useful include file and can be easily plugged into your code in it's entirety or in parts. Some functions aren't completely tested but seem to work so if you find something that doesn't work properly feel free to fix it and let me know so I can fix mine. It will chcek to see if DST is in affect or not based on the start and stop dates. I don't do anything with that info since I haven't seen any problems with what the astro_clock function returns but you can use it to display on your TP.
There's some other time functions in here that aren't needed for the code in this include but are used elsewhere in my code and since they are time related I decided to store them in the time include so they would be easier for me to find.
Since this is an .axi there are parts that this file needs that isn't in this file. If you find you can't figure it out on your own and need the missing parts just let me know. A few things may make you scratch your head and yes 8 space indents, camel case w/ hungarian notations and braces where no real programmer would ever put them so deal with it.
If anybody wants to improve the get_holiday function (add holidays) feel free but post your additions. -
Sorry about the delay - within the week I'll have beginnings of date/time common functions, including stuff that should be clkmgr functions but aren't, such as determining if daylight savings is currently active. I have a function written for that now, but hopefully I'll have other things. These will be part of the NetLinx Common Libraries.
-
haha, that still cracks me up.Joe Hebert wrote: »I don?t care about the local time +/- whatever argument (or parameter as Hedberg might call it.

--John -
Yup, I would definitely nominate Hedberg?s quip as a forum classic and something only a geek would enjoy.John Gonzales wrote: »haha, that still cracks me up.
--John
Leave a Comment
Categories
- All Categories
- 2.5K AMX General Discussion
- 922 AMX Technical Discussion
- 514 AMX Hardware
- 502 AMX Control Products
- 3 AMX Video Distribution Products
- 9 AMX Networked AV (SVSI) Products
- AMX Workspace & Collaboration Products
- 3.4K AMX Software
- 151 AMX Resource Management Suite Software
- 386 AMX Design Tools
- 2.4K NetLinx Studio
- 135 Duet/Cafe Duet
- 248 NetLinx Modules & Duet Modules
- 57 AMX RPM Forum
- 228 MODPEDIA - The Public Repository of Modules for Everyone
- 943 AMX Specialty Forums
- 2.6K AMXForums Archive
- 2.6K AMXForums Archive Threads
- 1.5K AMX Hardware
- 432 AMX Applications and Solutions
- 249 Residential Forum
- 182 Tips and Tricks
- 146 AMX Website/Forums
