ni-rt.ini RTTarget.OlsonTimeZone="EST"

[QFang]

Hi all, 

I am working on a small client/server app that I can run on the RT target to let me set the date, time and time-zone of the RT target. I got the time and date down just fine, but I'm curious on how to properly set the timezone information in the ni-rt.ini file on the target (cRIO-9014).

There seems to be two (redundant??) keys for time-zone in that ini file, these are found in the [LVRT] section and are:

RTTarget.OlsonTimeZone="EST"

RTTarget.TimeZone="EST5"

I had never heard of Olson time zones so I googled it, but according to wiki all the country codes are two letters long (ie. there is no "EST" defined in the list, or at least not as EST).. 

So my question is this:

Is there an easier way of getting a list of the GMT time-offsets along with the corresponding "NI Flavour" of "OlsonTimeZone" that the RT expects, and also the "TimeZone" "ABCx" tag?

(Easier than manually changing the time-zone in max, rebooting and checking the file for all the different time-zones available).

Thanks!

-Q 

[Christian Mergl]

Have a look at: Setting the Timezone of a LabVIEW Real-Time System

Christian

[QFang]

The string values that are written to the ini file using the VI you pointed to are not the same string values that get written if I use MAX to set the time-zone. Since the VI is around 5 years old, I would like to know if NI has changed the way RT targets parse and interpret the timezone tags before I adapt this solution to our shipping controller code?

Also, this VI does NOT update the RTTarget.OlsonTimeZone field in the INI file, which is specifically what I was asking about in the opening post. I still need to know if I need to set both fields, or what the purpose is of the Olson field so that I don't set us up for failure in remote deployed applications. 

Once my morning tasks are out of the way, I will play around with MAX vs this VI and report my findings here.

Thanks for the link and hope to hear back on the whole Olson thing soon!!

-Q 

[Texas_Diaz]

The OlsonTimeZone token was added when the NI System Config API was introduced a while back.  When you set a Time Zone within a version of MAX (that supports the NI System Config API) it will persist both the "Legacy" time zone information that we've had for a long time, but it also persists the Olson time zone information.  The "Legacy" and "Olson" time zone information is mapped via a file located on your target here:

• /ni-rt/system/timezone.ini

You'll notice it doesn't use the two-letter timezone information, instead it uses more the long information.  PharLap/VxWorks RT targets do not actually use the Olson time zone information, but instead they still just use the Legacy Time Zone information, but the Olson information is being persisted for other reasons (customer requests, a move toward standardization, etc...).

Here is a list of the valid "Legacy" timezones you can set within MAX, with the time offset:

   ===================================================================================================
     Without DST    With DST            UTC offset sec    String that shows up in UI drop down box
   ===================================================================================================
   ("UTC12",       "UTC12UDT",          -1200)        // (GMT-12) International Date Line West
   ("BST11",       "BST11BDT",          -1100)        // (GMT-11) Midway Island, Samoa, Bering Straits
   ("HST10",       "HST10HDT",          -1000)        // (GMT-10) Hawaii, Aleutian Islands
   ("MART9:30",    "MART9:30MARDT",      -950)        // (GMT-9:30) French Polynesia, Marquesas Islands
   ("AST9",        "AST9ADT",            -900)        // (GMT-9) Alaska
   ("PST8",        "PST8PDT",            -800)        // (GMT-8) Pacific Time (US & Canada), Tijuana
   ("MST7",        "MST7MDT",            -700)        // (GMT-7) Mountain Time (US & Canada), Mazatlan
   ("CST6",        "CST6CDT",            -600)        // (GMT-6) Central Time (US & Canada), Mexico City
   ("EST5",        "EST5EDT",            -500)        // (GMT-5) Eastern Time (US & Canada), Bogota, Lima
   ("AST4",        "AST4ADT",            -400)        // (GMT-4) Central Brazil, Santiago, Caracas, La Paz
   ("NST3:30",     "NST3:30NDT",         -350)        // (GMT-3:30) Canada (Newfoundland Standard Time)
   ("GRNLNDST3",   "GRNLNDST3GRNLNDDT",  -300)        // (GMT-3) Greenland, East Brazil, Buenos Aires
   ("FALKST2",     "FALKST2FALKDT",      -200)        // (GMT-2) Falkland Islands, Mid-Atlantic
   ("AZOREST1",    "AZOREST1AZOREDT",    -100)        // (GMT-1) Azores, Cape Verde Islands
   ("CUT0",        "CUT0GDT",               0)        // (UTC) Coordinated Universal Time
   ("GMT0",        "GMT0BST",               0)        // (GMT) Greenwich Mean Time, London, Lisbon
   ("NFT-1",       "NFT-1DFT",            100)        // (GMT+1) Continental Europe, West Central Africa
   ("WET-2",       "WET-2WET",            200)        // (GMT+2) Finland, Athens, Jerusalem, Bucharest
   ("USAST-2",     "USAST-2USADT",        200)        // (GMT+2) South Africa, Cairo, Istanbul, Beirut
   ("SAUST-3",     "SAUST-3SAUDT",        300)        // (GMT+3) Saudi Arabia, Kuwait, Iraq, Nairobi
   ("MEST-3",      "MEST-3MEDT",          300)        // (GMT+3) Moscow, St. Petersburg, Volgograd
   ("IRST-3:30",   "IRST-3:30IRDT",       350)        // (GMT+3:30) Iran
   ("WST-4",       "WST-4WDT",            400)        // (GMT+4) Abu Dhabi, Muscat, Baku, Tbilisi, Yerevan
   ("AFT-4:30",    "AFT-4:30AFDT",        450)        // (GMT+4:30) Afghanistan
   ("PAKST-5",     "PAKST-5PAKDT",        500)        // (GMT+5) Pakistan, Islamabad, Tashkent, Ekaterinburg
   ("IST-5:30",    "IST-5:30IDT",         550)        // (GMT+5:30) India, Sri Lanka
   ("NPT-5:45",    "NPT-5:45NPDT",        575)        // (GMT+5:45) Nepal
   ("TASHST-6",    "TASHST-6TASHDT",      600)        // (GMT+6) Almaty, Novosibirsk, Astana, Dhaka
   ("MMT-6:30",    "MMT-6:30MMDT",        650)        // (GMT+6:30) Myanmar, Cocos Islands
   ("THAIST-7",    "THAIST-7THAIDT",      700)        // (GMT+7) Thailand, Jakarta, Krasnoyarsk
   ("WAUST-8",     "WAUST-8WAUDT",        800)        // (GMT+8) Western Australia, Kuala Lumpur, Singapore
   ("TAIST-8",     "TAIST-8TAIDT",        800)        // (GMT+8) Taiwan, Beijing, Hong Kong, Urumqi, Irkutsk
   ("CWST-8:45",   "CWST-8:45AW",         875)        // (GMT+8:45) Western Australia (Caiguna-Eucla)
   ("JST-9",       "JST-9JSTDT",          900)        // (GMT+9) Japan
   ("KORST-9",     "KORST-9KORDT",        900)        // (GMT+9) Korea, Yakutsk
   ("CST-9:30",    "CST-9:30AS",          950)        // (GMT+9:30) South Australia, Northern Territory, Broken Hill
   ("EET-10",      "EET-10EETDT",        1000)        // (GMT+10) Eastern Australia, Guam, Hobart
   ("LHST-10:30",  "LHST-10:30LH",       1050)        // (GMT+10:30) Lord Howe Island
   ("MET-11",      "MET-11METDT",        1100)        // (GMT+11) Solomon Islands, New Caledonia, Magadan
   ("NFT-11:30",   "NFT-11:30NFDT",      1150)        // (GMT+11:30) Norfolk Island
   ("NZST-12",     "NZST-12NZDT",        1200)        // (GMT+12) New Zealand, Fiji, Kamchatka
   ("CHAST-12:45", "CHAST-12:45CHADT",   1275)        // (GMT+12:45) New Zealand (Chatham Islands)
   ("TOT-13",      "TOT-13TDT",          1300)        // (GMT+13:00) Nuku'alofa

However,  you can set any timezone you want - and you can see this from the values above.  All RT is really looking for is some combination that fits this pattern:

• [LETTERS][+-][NUM][OPTIONALLETTERS]

It looks for LETTERS to know that a number is going to follow.  The number is the time offset, and may contain a + or - if there is need.  Then, it looks for more letters afterwards - if there are more letters after, then it applies the US DST rules to the timezone.

So, if I wanted to have a timezone that was 2 hours and 13 minutes behind GMT, I could use this:

• RTTarget.TimeZone="DAN-2:13"

And, if I wanted it to follow US DST rules, I would then do this:

• RTTarget.TimeZone="DAN-2:13DDT"

If I want to use a DST that did not follow the US DST, that requires some extra work (I'll save myself the lookup unless there's high demand for it).

-Danny

[QFang]

Hi Danny!

Thanks for the detailed answer, this was exactly what I was looking for and I truely appreciate it!

I still have a couple of questions, if you don't mind:

So, if the Olson time is not used by the target(s) at this time, do I even need to set it? -I noticed that the Olson time tag only appears in the NI-RT.ini file if you install certain extra modules onto the cRIO. For a plain install (recommended package with no additional modules) this tag does not appear in the ini file, so I'm guessing I could just set it to the same tag value as the "legacy" tag for time-zone and then I should be safe now and in the future?

Finally, I would like to ask you to dig in for the additional dayligt savings time for non-US regions and how I should best handle that. Is there a whitepaper on this? MAX indicates that the cRIO (9014) does not support automatic daylight savings adjustments, but your post eludes to some sort of solution existing still? We deploy systems on a global scale so this really would be the icing on the cake for me/us.

If you want I could submit this as a formal support request ticket in case it allows you to spend more time on this and/or internal tracking purposes?

[Texas_Diaz · Accepted solution]

It's recommended that you use the NI System Config API to set things like this on your target, in case in the future it's required to set Olson timezone information (and anything else you may not have found).  As of LabVIEW RT 2011SP1 (which is the current latest-and-greatest), we do not use that setting on the target and it's not required to be there - right now the NI System Config API puts that on the target because they're working to standardize how we do these sorts of things with the "rest of the community."  This does not guarantee that components in the future won't use the Olson timezone information - and require that the information be present on the target - in order to function properly.  

Unfortunately, your documentation is correct - VxWorks based controllers do not have the ability to set automatic DST adjustment rules.  However, PharLap-based controllers (including the cRIO-9002 / cRIO-9004 and cRIO-9081 / cRIO-9082 controllers) can do this.  Setting the DST on PharLap is fairly easy.  You would need to modify the following token:

[LVRT]

RTTarget.DSTRule = dm.dw.dd[.dh[.dm]][,sm.sw.sd[.sh[.sm]]]

This may be fairly straightforward, but you set the d (daylight saving time) and optionally the s (standard saving time) with this token, setting the month, week, and day (and optionally the hour and minute) that the change should take place.

For example, if we were to set the US rules manually, the standard US rules DST(3=March, 0=Sunday, 2=Second Week, 2=2AM, 0=0Min) STD( 11=November, 0=Sunday, 1=Week1, 2=2AM, 0=0Min) would be defined as such:

[LVRT]

RTTarget.DSTRule = 3.0.2.2.0,11.0.1.2.0

-Danny