Time Stamp in Raspberry Pi 4

[DavidWilt]

This forum post here is actually where I have learned most of my Linux and I have to give credit to Rolf here with helping me to learn what I know so far.

On the LabVIEW side I have never used the Get Date Time String function you used.  I always use the Format into String function and find it very useful.  I am sure each have their own purpose.

The forum is for helping and I am glad to help where I can.

[rolfk]

You can install additional timezones in the LabVIEW chroot environment through the opkg command:

opkg update
opkg list tz*

This will give you a list of packages that contain various timezone settings depending on (loosely) continents.

One of the packages listed should probably contain your timezone settings. After you installed it with

opkg install tzdata-<your area>

the according file should be present in the /usr/share/zoneinfo

The LabVIEW Get Date/Time string always returns the time in local time. Which for your system is UTC since you changed the timezone settings in the chroot to use UTC. If you want the local ART time you need to change the timezone accordingly INSIDE the chroot. So the formatting for the Get Date/Time string happens on the RPI according to the timezone settings of your LabVIEW chroot environment. The timezone setting of your Raspbian host system does not matter at all.

But the "current time" control is a timestamp which internally always stores date/time in GMT (equivalent for our purposes to UTC). This GMT timestamp is then transferred to your Windows computer through the debug channel and to the front panel which runs on your Windows computer, so LabVIEW for Windows converts the timestamp into a string according to your Windows local timezone settings. Since your Windows computer is almost certainly set to local ART time, there you get a 3 hour difference between the two. It's all very logical and even if it can cause knots in your synapses, an unavoidable result of the fact that our earth really is a round ball that turns around its own axis.

The Format String function also uses by default local time formatting. You can change that by changing the formatting string from %T to %^T, which will cause the time formatting to be in UTC.

If you use a custom format rather than the platform default time and date format you would change the format string from %<your detailed format>T to %^<your detailed format>T.

The caret right after the percent sign indicates to use UTC instead of local timezone.

You always need to consider where the formatting of the time string happens and according to which rules. LabVIEW tries to make it as consistent as possible by maintaining timestamps internally always as GMT. But this timestamp value would be hard to digest for humans (current time really would look something like: 3693547745.784101324185665536) so the timestamp control also converts this timestamp to a normal time string on the computer system the front panel is executed. Yes you would probably prefer if LabVIEW was instead transfering an image of the local front panel to your Windows system, except LabVIEW on the Raspberry Pi and really most other embedded targets doesn't even have front panels. Also if your RPI is located in Africa and you debug it from your home location over the internet there is something to say to show you your local time for timestamps transmitted through the debug link, so if that timestamp reads your current local time you know it was just generated instead of showing a time some 4 or 5 hours ago. Of course there will always be situations where this feels wrong, but the problem with this is that whatever LabVIEW does here, it will feel wrong and unintuitive to about half of the people. So LabVIEW chose to do the scientific more correct way here. If you really need to know the local time of the system itself you can always convert the timestamp into a string on the system and transfer this string to your debug front panel.

[Choke]

Rolfk, 

I think I have understood your last post.

In order for "Get Date / Time Strig" or "Format Into String" to give the local time, the time zone must be configured correctly within "schroot -r -c lv". It is right?

As you can see in the attached image, now the time zone of my country does exist, after executing "opkg update" and installing my time zone with "opkg install datazone-Americas".

So, from this instance, what would be the steps to follow for the Labview environment to deliver the local time and not 3 hours ahead?

I have followed, again, the steps David suggested, but I was unable to get the "date" command to deliver the local time within the Labview environment.

Total thanks

[DavidWilt]

Choke,

You LabVIEW chroot is not using a timezone per your latest image.  If you have the timezone set then the date command would return with your configured timezone.  For example here is what I see when I have my set to America/Chicago:

You are still on step #2 of what I have outlined previously.  Get the LabVIEW chroot to display with your timezone using the date command and then let me know what you see in LabVIEW.

[Choke]

David, image attached.

[DavidWilt · Accepted solution]

Choke,

You don't want UTC, right?

Issue this comment in the LabVIEW chroot:

ln -sf /usr/share/zoneinfo/America/Argentina /etc/localtime

Then do the date command again.  If the time is still returned in UTC then the timezone did not take.  The date command does not handle errors well and will just return the time in UTC if there is an issue. 

[rolfk · Accepted solution]

Note also that you did explicitly configure your chroot to UTC as shown in the zoneinfo picture in your post here. You may have to first delete your /etc/localtime symbolic file entry before you can create a new one as David told you.

rm /etc/localtime

 After that you should be able to create the new symlink as explained by David.

[Choke]

The time zone in Argentina is UTC-3.
Responding to David: yes I want to see UTC.
And, indeed, with your procedure you can change the time zone from, for example, UTC to EST. I did it and it works.
What does not work is the local time which is the time delivered by UTC minus 3.
Attached Image of the time zone and the Rpi command terminal.

[rolfk · Accepted solution]

Your /usr/share/zoneinfo/America/Argentina is a directory that contains different timezone files depending on the city. So your correct command is most likely:

ln -sf /usr/share/zoneinfo/America/Argentina/Buenos_Aires /etc/localtime

or one of the other cities in that directory if closer to you. 

[Choke]

Perfect !!!!
See the pictures.
Now the time of the Labview environment coincides with the local time of Argentina.
I have run the VI and as you can see "current time" equals "resulting string"

Thank you, thank you very much David, too.