Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. Hi, now is EasyXml at github. I made a pull request with the fix https://github.com/JKISoftware/JKI-EasyXML/pull/1 Peter
  2. Hi Jim, the answer was at Dec 15 08:38 AM: We do not have a version to release yet and will certainly notify you when we have one with the fix. It's not a problem for me. I fixed the bugs in my installation. But nobody else use Timestamps on non english systems and in timezones with daylight saving? Fortunately its only one hour. Peter
  3. Hi Vikas, in the official EasyXML Package is the bug: the utc offset doesn't depend of the input time. It is calculated from a fixed date (1/1/1904). For me in europe it is always +01. But for a time inside daylight saving it should +02. For me I fixed this UTC offset bug ( remove vi password - see hmilch.net, search the bug, fix the bug...) Easyxml is closed source, so I can not publish the fix. Peter
  4. Hi Jim, it was a never ending story - the last mail was from 3. Jan 13: We have this issue fixed and will be included in a future release of the toolkit. Hence, I will close this ticket. But I never got an update. Because I had to finish some projects I couldn't wait and fixed it for me in the source. In a new system with LV2012 and the actual VIPM is still the bugged demo Version 2.0-1: The xml time 2014-09-12T15:02:38,458+01:00 should be 2014-09-12T15:02:38.458+02:00 Where can I get an actual update with the fixes?
  5. I know. But why I use EasyXML. It can create XML from clusters: But the UTC Offset was in September +02:00 ! Easy XML use not UTC Offset from the time value. And you see I fixed the bug "Timestamp decimal is no period". For my LV 2012 installation I fixed also your UTC offset bug. So correct is: The problem was: I had to read the times in c# and with your bug is an hour offset! It would be very usefull, also for other users, if you fix the bugs in the offical packages (eval + registered).
  6. Hi Ton, that is not a Labview bug. There is no Localization Code %.; for the Period decimal separator in the format string for the "Format Into String" Function to convert the time stamp to the xml string. See http://zone.ni.com/reference/en-XX/help/371361J-01/lvconcepts/format_specifier_syntax/ Without the Localization Code %.; the "Format Into String" Function use the System default separator. And in many countries this is ",". Peter
  7. Hi Ashish, then I get the local time with UTC offset ( which is not correct because the 1 hour DST offset is missing): <Time_Stamp>2014-05-13T13:40:36.121+01:00</Time_Stamp> The UTC Format <Time_Stamp>2014-05-13T11:40:36.121Z</Time_Stamp> is not possible? Peter
  8. Hi, Is there an option to save a timestamp as UTC xml string ? Example: <Time_Stamp>2014-05-13T11:40:36.121Z</Time_Stamp> Peter
  9. I read the xml string with c# code and deserialize it. The result return an offset of 1 hour: Time_Stamp {13.05.2014 14:40:36} System.DateTime
  10. Hi, an actual datetime is converted to <Time_Stamp>2014-05-13T13:40:36.121+01:00</Time_Stamp> The +01:00 should be the UTC offset. But my UTC offset is +02:00. So I assume, the daylight saving offset of 1 hour is not considered. I have a small vi, which calculate the TimeZoneBias. A little modification should calculate the correct UTC offset. Peter
  11. Hi, I test the demo Version 2.0-1 ( installed with VI Package Manager) it create an xml from timestamp with the local decimal symbol "," instead of ".". <Calibrationtime>2012-11-28T16:08:39,344+01:00</Calibrationtime> I have to read it with c# Deserialize. I get an exception: InnerException: System.FormatException Message=Die Zeichenfolge '2012-11-28T16:08:39,344+01:00' kein gültiger AllXsd-Wert. Source=System.Xml I see, there is an old Known Issue (Case 5099): Timestamp decimal should be forced to use a period. Posted 04 March 2008, Versions Affected: 1.0 In Version 2.0 there was no fix? How can I: - use a period as decimal symbol - or format the time stamp without fractional of seconds ( I don't need it) Peter
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.