FHIR Chat · Annoying bug, not valid AllXsd value · conformance

Stream: conformance

Topic: Annoying bug, not valid AllXsd value


view this post on Zulip Thomas Tveit Rosenlund (Jan 03 2017 at 08:24):

Just tried 14.4.1 version of Forge today, but can't do anything with it. As I get a bug when I choose a resource to profile (any resource). The earlier version I have installed works fine but its kind of old (13.2). Will appreciate any help. By the way I run this in a Virtual Machine, Windows 10 because of my companys policy regarding third party software.

ERROR message:

2017-01-03T09:20:58
Forge Forge 14.4.1 for DSTU2
FHIR DevDays 2016 Edition (hotfix)
Version: Version 14.4.1.0 (ClickOnce)
FHIR Version: Fhir.NET library for 1.0.2


FormatException in System.Xml:
The string '2017-01-03T09.20.48+01:00' is not a valid AllXsd value.
at System.Xml.Schema.XsdDateTime..ctor(String text, XsdDateTimeFlags kinds)
at System.Xml.XmlConvert.ToDateTime(String s, XmlDateTimeSerializationMode dateTimeOption)
at Forge.ViewModels.FhirDateTimeExtensions.GetValue(FhirDateTime source)
at Forge.ViewModels.DateTimeStorageHandler..ctor(IViewModel property, Object instance, PropertyInfo propertyInfo, Object baseInstance, Boolean isForced)
at Forge.ViewModels.ProfileVM.set_ModelElement(Base value)
at Forge.ViewModels.ProfileVM.Initialize(Base modelElement, Base baseElement)
at Forge.ViewModels.ProfileVM..ctor(ISessionItem owner, StructureDefinition model, StructureDefinition baseModel, String contentDirectory)
at Forge.ViewModels.ProfileVM.New(ISessionItem owner, TypeReference typeRef)
at Forge.ViewModels.SessionItemVM.<>c__DisplayClass121_0.<AddNewProfile>b__0(ISessionItem owner)
at Forge.ViewModels.SessionItemVM..ctor(ISessionItem owner, Func`2 resourceFactory, Boolean isFolder, Boolean isPackageFolder, Boolean isResourceFolder)
at Forge.ViewModels.SessionItemVM.AddNewProfile(TypeReference typeRef)
at Forge.UI.Views.MainPage.<>c__DisplayClass16_0.<NewProfile_Return>b__0()
at Forge.UI.Views.MainPage.<>c__DisplayClass5_0.<SafeAction>b__0()

view this post on Zulip Michel Rutten (Jan 03 2017 at 10:55):

@Thomas Tveit Rosenlund the time part "09.20.48" has an incorrect/unrecognized format (expecting 09:20:48, so with semicolon as separator). I can't immediately reproduce the issue on my machine, but I'll investigate further. Could be b/o localized datetime formatting settings on your machine.

view this post on Zulip Thomas Tveit Rosenlund (Jan 03 2017 at 11:12):

Thanks for your input @Michel Rutten . Just tried changing my Region/Change location/Format setting from Norwegian to English (UK). And that did the trick. Somehow that regional setting overrides the time parameter in the latest Forge build to produce Norwegian time format somewhere, and that obviously triggered the bug. Thanks for the prompt reply!

view this post on Zulip Michel Rutten (Jan 03 2017 at 12:05):

Hi @Thomas Tveit Rosenlund that confirms my suspicion. I'm still trying to reproduce the issue in code by forcing a custom locale. Is your machine configured for the nn-NO locale?

view this post on Zulip Thomas Tveit Rosenlund (Jan 03 2017 at 12:19):

Hi @Michel Rutten, my machine was configured to the nb-NO locale, and still is. I had to change the format settings specifically for time to get rid of the bug.

view this post on Zulip Thomas Tveit Rosenlund (Jan 03 2017 at 12:19):

Skjermbilde-2017-01-03-13.13.12.png

view this post on Zulip Michel Rutten (Jan 03 2017 at 14:04):

Note to all: the issue proved to be related to regional (datetime format) settings. This will be fixed in the forthcoming Forge update.

view this post on Zulip Brian Postlethwaite (Jan 04 2017 at 06:11):

Was that a forge issue, or .NET fhir client parser issue?

view this post on Zulip Michel Rutten (Jan 04 2017 at 09:17):

Looks like this isue was fixed b/o some recent changes in the FHIR .NET API, specifically the FhirDateTime ctors now using XmlConvert.ToString to convert XML datetime strings to C# native DateTime(Offset).

view this post on Zulip Michel Rutten (Jan 04 2017 at 09:20):

In Forge, I call a different (newer) overload with an additional parameter:
XmlConvert.ToDateTime(value, XmlDateTimeSerializationMode.RoundtripKind)
This seems to better handle timezone offset conversions. Maybe the FHIR .NET API should do this too... thoughts?


Last updated: Apr 12 2022 at 19:14 UTC