LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Format Specifiers Syntax does not support AM/PM flag

No it is not a bug.  It is because no one has ever believed you should have some hybrid time format that has both a 24 hour clock, and an AM/PM clock.

 

Looking at your last snippet, it certainly looks like the top indicator should be outputting a 12 hour clock with an am/pm flag, but is not.  Perhaps on your computer, the flag for AM/PM is not defined and it is just outputting an empty string.  What is the designation for AM/PM in French?

 

I ran your snippet on my Windows PC and changed my time format to be a 24 hour clock, and it seems to run just fine.

 

Message 11 of 17
(1,872 Views)

I agree with RavensFan,

 

I have Windows 7 (french version), and I don't have anything specified as "Symbole AM" and "Symbole PM" as shown below.  If I put something in the symbole I will see them in the code snippet you sent (but you must re-start LabVIEW after modifying Symbols).

 

AM: Before noon when using 12 hrs clock.

PM: After noon when using 12 hrs clock.

 

Julien: I just read previous post where one of the requirement is "you don't have administrator" priviledge.....

 

timesettings.jpg

0 Kudos
Message 12 of 17
(1,864 Views)

But this should only have to be fixed one time on the PC and the settings should stick after that.  So requiring admin privileges for a single time such as when you are installing software is really not that unreasonable of a requirement.

0 Kudos
Message 13 of 17
(1,848 Views)

Perhaps, but if you have to do that on thousand of industrial computers around the world... (more : all of this computers and their softwares are managed by another company, and this software have to work on a USB key on a Windows account without any sort of administrator privilege (even we cannot explore any folder, change any setting (for exemple clock...)), so if you have to do that : your boss has to say "find a trick"... so I made a workaround!).

 

I think almost it could be written in the LabVIEW help of functions that use time format, that is impossible (without tricking the string and deal with special cases of 12am and 12pm (Michel follow that link)) to display in a string indicator %I:%M:%S %p (with a am/pm flag) on a international standard of 24h time format computer settings (like meters rather miles, or kg rather gallons, etc. like this you can avoid crashing a spatial probe on some ground Smiley Happy). And it could be write that if you change regional setting you have to rebbot LabVIEW. I think for this 2 points, it's almost a lake of documentation if this not a bug.

 

@ :  the am/pm notation is from latin and avalaible in french (a lot of English words etymology's come from french and/or latin), but to avoid confusion we use, without exception, in writting situation the 24h format for a long time, and to make simple : on verbal discussion we use the 12h but if context is unsufficient we specify morning or afternoon.

 

So, I code a solution (my previous post ‎2015-10-21 12:20 PM (UTC or not?Smiley Wink)) that isn't elegant but functional, so thanks you.

Julien
Message 14 of 17
(1,833 Views)

It is not a bug.  LabVIEW uses the operating system defined definitions of AM/PM for when you use the %p flag.  It is not LabVIEW's fault if the OS never bothered to defined any strings for AM/PM.  That is a bug within the operating system.

0 Kudos
Message 15 of 17
(1,818 Views)

@M.Julien wrote:

Perhaps, but if you have to do that on thousand of industrial computers around the world... (more : all of this computers and their softwares are managed by another company, and this software have to work on a USB key on a Windows account without any sort of administrator privilege (even we cannot explore any folder, change any setting (for exemple clock...)), so if you have to do that : your boss has to say "find a trick"... so I made a workaround!).

 

I think almost it could be written in the LabVIEW help of functions that use time format, that is impossible (without tricking the string and deal with special cases of 12am and 12pm (Michel follow that link)) to display in a string indicator %I:%M:%S %p (with a am/pm flag) on a international standard of 24h time format computer settings (like meters rather miles, or kg rather gallons, etc. like this you can avoid crashing a spatial probe on some ground Smiley Happy). And it could be write that if you change regional setting you have to rebbot LabVIEW. I think for this 2 points, it's almost a lake of documentation if this not a bug.

 

@@RavensFan :  the am/pm notation is from latin and avalaible in french (a lot of English words etymology's come from french and/or latin), but to avoid confusion we use, without exception, in writting situation the 24h format for a long time, and to make simple : on verbal discussion we use the 12h but if context is unsufficient we specify morning or afternoon.

 

So, I code a solution (my previous post ‎2015-10-21 12:20 PM (UTC or not?Smiley Wink)) that isn't elegant but functional, so thanks you.


The best way to represent a timestamp in string format with portability is with ISO 8601.

 

The 8601string format is widely accepted, represents time in 24 hour format, and can even handle UTC. Smiley Surprised

 

Se my signature below for 8601. (Now is the right time to use...)


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Message 16 of 17
(1,804 Views)

Hello,

For sure ISO format is best, but I don't know how many people use your format that give the time for UTC, but for data logging this is certainly more reliable, I agree with you!

But for people who doesn't use UTC time zone (Z), you can use this format %<%Y-%m-%dT%H:%M:%S%3u%z>T (with or without the 3 decimales of second).

But Smiley Very Happy ... there is another "bug" : the %z don't display the positive offset with UTC, ISO 8601 required the sign of the offset.

UTC offset.png

Ok : I add a space before the UTC offset for display conveniance, but I think ISO say not.

With negative offset this is OKUTC negative offset is OK.png

With positif offset, this is not OK : UTC positive offset is KO.png

 

So thank you all guys (or girls?!) for your investigations, even if I think my solution is not elegant (deal with am/pm string, rather than customizing Windows regional settings), it works!

 

Julien
0 Kudos
Message 17 of 17
(1,760 Views)