10-22-2015 09:56 AM - edited 10-22-2015 10:09 AM
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.
10-22-2015 10:18 AM - edited 10-22-2015 10:25 AM
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.....
10-22-2015 11:19 AM
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.
10-22-2015 12:01 PM - edited 10-22-2015 12:11 PM
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 ). 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?)) that isn't elegant but functional, so thanks you.
10-22-2015 03:34 PM
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.
10-22-2015 05:39 PM - edited 10-22-2015 05:44 PM
@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 ). 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?)) 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.
Se my signature below for 8601. (Now is the right time to use...)
10-23-2015 11:36 AM
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 ... there is another "bug" : the %z don't display the positive offset with UTC, ISO 8601 required the sign of the offset.
Ok : I add a space before the UTC offset for display conveniance, but I think ISO say not.
With negative offset this is OK :
With positif offset, this is not OK :
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!