In the image zoneinfo.png you can see that the time delivered by labview is three hours ahead of the one shown by the raspberry pi, at the top right of the same image.
This is what you ask me?
In the command:
ln -sf / usr / share / zoneinfo / EST / etc / localtime
Instead of EST I have put UTC.
But in Argentina the local time is UTC-03, as you can see in the attached image.
Is there a way to fix that in Labview?
There is no LabVIEW whatsoever involved in these images. Your last image is from the Raspberry host system which is what seems consistent. The first two are inside the chroot environment which seems ok. This is also a Linux OS, just a somewhat older version than your Raspbian (in principle a Debian Buster distribution I think).
You have localtime 12:21 UTC in that command window, while your Raspbian host has local time 09:30 (I assume it took you 9 minutes from entering the date command to taking the screen shot.
This looks consistent. Your Raspbian host shows Argentinian local time in the menu bar, while your chroot has been changed to UTC as local time and according to you Argentinian timezone offset is UTC - 3 hours. So 12:30 UTC will turn out to be 9:30 Argentinian local time. So far everything looks right. The timezone settings inside the chroot environment have no influence on what the Raspbian host thinks the current local time is.
Now run a LabVIEW VI in the chroot and compare its time to what the date command shows at that moment in the command line. And beware here: If you remote debug your VI from the Windows computer what will happen is that the timestamp will be computed on the RPI according to the chroot timezone setting, then transfered as seconds since Jan 1, 1904 GMT (which is basically equal to UTC) to your Windows host and there the display in the front panel will be adjusted for the timezone settings of your Windows host! And if you feel that is complicated, then yes it is but there is no way around that unless the Flat Earth Society turns out to be right so we can abandon all that timezone nonsense! 😁
Choke what I believe that you are missing is that the there are 2 different Linux OS running on the RPi. The LabVIEW chroot is in its own Linux OS so changing the timezone in Raspbian will never effect the timezone in the LabVIEW chroot. This needs to be ran in the LabVIEW chroot to set the timezone there.
ln -sf /usr/share/zoneinfo/EST /etc/localtime
Then run date in the LabVIEW chroot to get the time. Understanding this you will be able to have 2 different timezones configured on the RPi as each Linux OS can have a different timezone. As far as I know there is no way to link the 2 timezones in each of the Linux OS without having code that sets one based on the other. You would be able to accomplish this if you refer to the GitHub repository I referred you to earlier.
Before moving to step 3 make sure you can change the timezone in the LabVIEW chroot and get the time there based on your timezone change.
Sorry, I think it was not understood what I wanted to express in the previous post.
It has become very clear to me that I must configure the time zone within the Labview environment in: "sudo schroot -r -c lv", is what I have tried to do.
I have attached the image "raspi-config.png" just to compare the output "date" of the labview environment with the output generated by "raspi-config" of the host system of the Raspberry Pi, after setting the time zone.
Inside the chroot, and as David explains, I have changed the time zone using: "ln -sf / usr / share / zoneinfo / UTC / etc / localtime", and as Rolfk says:
"Your Raspbian host shows Argentinian local time in the menu bar, while your chroot has been changed to UTC as local time and according to you Argentinian timezone offset is UTC - 3 hours. So 12:30 UTC will turn out to be 9:30 Argentinian local time. So far everything looks right. The timezone settings inside the chroot environment have no influence on what the Raspbian host thinks the current local time is ".
I understand that they are two different Linux, but they should both deliver the same time.
I'm going to try to run a VI in the chroot environment that displays the time on a Window front panel.
Then I'll run it as a startup, but it generates a ".csv" file and in which the date and time are printed.
Then I will show you the results.
I think I understand what you are asking now.
What you are saying is that in Raspbian there is a timezone available for your local time America/Argentina/Buenos_Aires
But in the LabVIEW chroot this timezone does not exist.
So you are asking how do you get your local time in the LabVIEW chroot if the timezone file does not exist, correct? The easiest way is probably to copy the timezone file that you want from Raspbian to the LabVIEW chroot. The reason that the available timezones are different in each of these areas is probably due to the different versions of Linux running in each location.
Dear I ran a VI inside the schroot environment.
First run it connected to the Rpi and with front panel in Windows.
Attached images of the VI block diagram and front panel.
As you can see, "current time" delivers the time correctly, but "Get Date / Time String" delivers the time 3 hours ahead.
Also run the program as a startup generating the file "viaMail_1" of which I attach an image.
As you can see there, the time is also 3 hours ahead.
Please if you find the problem share it here.
And not least, excuse my English.
Choke I believe what you are using is expected because according to the help on that function the string is time zone independent: https://zone.ni.com/reference/en-XX/help/371361R-01/glang/get_date_time_string/
Why not use the Format into String function, https://zone.ni.com/reference/en-XX/help/371361R-01/glang/format_into_string/, with the time formatting strings, https://zone.ni.com/reference/en-XX/help/371361R-01/glang/codes_for_time_format_str/.
If current time is in the time you expect then it appears that the RPi is configurated correctly.
David, thanks for taking the time.
This is how you dice it.
I am not a champion on Linux, but I will try to.
I hope it works.