A bug related to TimeZone setting in PharLap v3.5

[Xu]

I think there is a bug related to TimeZone setting in PharLap operating system version 3.5 for FieldPoint FP-2015 controller.

Test environment: FieldPoint FP-2015 controller with PharLap version 3.5 and Time Server set to a PC running Windows XP;
LabVIEW 7.1 developement environment;
MAX version 3.1.0.3021.

The attatched is a VI to append current date and time to a text file, corresponding to the current locale of the operating system.
When it is targeted to the FP-2015 and run, Date/Time string written in the text file should be the current locale date/time on FP-2015. However, for some locales it does not work -- it writes Coordinated Universal Time to the file. I used MAX to set locale on FP-2015. For example, the time server's locale is Eastern United States(-5), datetime is 2005-Jan-1 13:00:00. When FP-2015's locale is Norway(+1), the datetime written to the file is 2005-Jan-1 19:00:00 (correct). When FP-2015's locale is Turkey(+3), the datetime written to the file is 2005-Jan-1 18:00:00 (not correct).

Below is a list of locales I have tested and the test results,
LOCALE WORKS or NOT
------------------------------------------------------------------
Easten United States Yes
Easten Australia Yes
Japan Yes
Korea No
Westen Australia No
Taiwan No
Thailand No
Central Asia No
Pakistan No
Gorki, Central Asia, Oman Yes
Turkey No
Saudi Arabia No
Finland Yes
Norway Yes

The bug could be in PharLap v3.5 and/or "Format Date/Time String" vi. I have no time to do more test. I think it is the most possible in PharLap.

Xu

[Xu]

Sorry, the "locale" in the above post should be "timezone".

[e-Cash-Money]

Hello Xu,

I have been trying to reproduce the behavior you are seeing but so far I have been unsuccessful. Regardless of what the time zone setting is in MAX for my FP controller, the output of the "Format Date/Time String" vi is always given to me in GMT time. Could you tell me a little bit more about your setup? Specifically, are you running the vi as an executable to run upon boot-up of the controller? What IP address is your time server set to and what is the IP address of your FP?

Also, the information contained in the following Knowledge Base articles might be useful to you.
http://digital.ni.com/public.nsf/websearch/234A454D5486C02E86256B6000631068?OpenDocument
http://digital.ni.com/public.nsf/websearch/C4E56AD6450FC5FD86256DFF0007FF01?OpenDocument

Thanks,
E.Lee
Applications Engineer
National Instruments

[Xu]

Hi E.,

Thank you very much for your responce.

I am not running the vi as an executable. I target LabView to FP, then open and run the vi.
The IP addreses are set as below:
FP-2015: a.b.c.68
Subnet mask: 255.255.255.0
Gateway: a.b.c.254
DNS server: a.b.202.10
Time Server: a.b.c.160 (PC with WIndows XP)

I tested again after getting your responce. Below are the procedure and the result.

1. Timezone of the time server: GMT-02:00 Mid-Atlantic (No daylight saving).
2. Using MAX to set FP's timezone to Norway (GMT+01:00), apply the setting and reboot FP.
3. Target LabVIEW to FP, open and run time.vi. Now the time at the time server is 15:38:xx (That is GMT17:38:xx).
4. FTP to FP, CD to temp folder on FP, get time.txt file from FP to my computer (the time server).
5. Open time.txt file, the time recorded is 18:38:xx (This is Norway local time: GMT+01:00).
6. Using MAX to set FP's timezone to Turkey (GMT+03:00), apply the setting and reboot FP.
7. Repeat 3. - 5.. Now time at time server is 15:44:xx (GMT17:44:xx ), time recoeded in time.txt file is 17:44:xx (GMT time).

What is wrong? Thank you again,

Xu

[e-Cash-Money]

Hello Xu,

Thanks you for all the information and the step-by-step procedure. I was able to verify the behavior you are seeing but I'm not sure what is causing the issue. I will continue to work on this to find out what is going on!

Thanks,
E.Lee
Applications Engineer
National Instruments

[Xu]

Hi E.,

Thank you for your relpy and the verification. I am looking forward to hearing the result. Thanks,

Xu

[e-Cash-Money]

Hello Xu,

I was not able to determine what is causing this behavior. Because of this, I have escalated this issue to our R&D department so they can look into resolving it in a future revision of the FP software/hardware which is causing the problem. Thank you for reporting this issue, we greatly appreciate your feedback.

In the meantime, I think the easiest workaround would be to add the known time offset to the timestamp programmatically in LV.

Take care,
E.Lee
Applications Engineer
National Instruments