Stupid DST Stuff!

itismyworld

I know there are lots of posts regarding this and I still can't understand why when DST changes in clock manager, that the time changes correctly but the sunrise/sunset times don't. Maybe something's changed and I'm missing it???
Assuming things are the same, I'm trying to get the return string from the master when I send: CLKMGR_GET_START_ DAYLIGHTSAVINGS_RULE()

On a button push, I have:
DST_START = CLKMGR_GET_START_DAYLIGHTSAVINGS_RULE()

This returns:
occurrence:2,1,3,2:0:0

Great!

Now here's the stupid question...where the hell can I grab this string to parse it? I would assume the STRING: on the DATA_EVENT of my master. So for trial purposes I have:

DATA_EVENT[dvMASTER]
{
STRING:
{
IF (FIND_STRING(DATA.TEXT, 'occurrence:',1))
{
TEST_VAR = 1
}
}
}

My TEST_VAR never changes. What am I doing wrong??? Pointers, tips, hey you idot are all welcomed! Thanks.

a_riot42

You don't want to have a data_event on the master, that can cause weird problems. I don't' think I understand your question though. You have the string in your variable DST_START, so I don't understand why you don't just parse it once you have it. The result won't be in the form of a string from the master like you have set up with your data_event. The string is returned in code when you call the function directly from the firmware. Call the function, get the string and then parse it to your hearts content.
Perhaps I don't understand what you need to do here...
Paul

itismyworld

Thanks Paul. Totally just parse it once I have it...duh! Works fine of course...don't know what I was or wasn't thinking.
I would however like to know how you call a function directly from the firmware. Never been taught that.

a_riot42

itismyworld wrote: »

Thanks Paul. Totally just parse it once I have it...duh! Works fine of course...don't know what I was or wasn't thinking.
I would however like to know how you call a function directly from the firmware. Never been taught that.

Well any built in function like length_string, or CLKMGR_GET_START_DAYLIGHTSAVINGS_RULE is going to be executed by the operating system, which is what I am referring to when I say firmware.
Paul

ericmedley

A couple things...
First, the sunrise/sunset (I can't help singing the song from The Fiddler On The Roof in my head when I type this) function is setup correctly (per other programming/engineering environments) to work from GMT. Daylight Saving Time is an oddity and is something we seem to want to afflict ourselves with.

So, the thought is essentially we are responsible for adjusting for DST ourselves. In my programming I dealt with this many moons ago. (Prior to the NI masters having an actual clock manager that hit a NTS) at runtime, I do a quick check to see if we're in DST or not, then the flag is used as an offset when calculating sunrise/sundet (

♫♫....)

times.

Second, one of the things I find interesting about the NIST time standard is that the protocol doesn't really give you a reliable way to know if we are celebrating DST or not. The old NIST telnet time server had a neat little way of dealing with the issue. There was a single integer format that was really helpful. If the value was a zero, we are in standard time. If the value was 51, we were in DST. as the date approached to switch the clocks from DST to Standard, the integer began counting down the days. When it counted down to zero we were in standard time. Then next time ti would click up to 100 and count back down to 51.

Nowadays we kinda need to know at the client-side that we're all going to start pretending the day has magically shifted on the thrid sudnay of November if a fish with two heads is caught on a new moon...

I realize most of this is me just carping about DST. So, I'll stop whining.