Opened 11 years ago
Closed 11 years ago
#2467 closed defect (fixed)
MgOutOfRangeException when selecting features whose DateTime entry pre-dates 1970
Reported by: | kshippey | Owned by: | |
---|---|---|---|
Priority: | medium | Milestone: | 2.6 |
Component: | Map Agent | Version: | 2.5.0 |
Severity: | major | Keywords: | MgDateTime Selection Error |
Cc: | External ID: |
Description ¶
Mapguide 2.6 version throws an Out of Range exception any time a feature is selected if its date property is before Jan 1, 1970. This traces to a use of the MgDateTime::ToTimeValue() to return date attribute data; this did not occur in Mapguide 2.5. The query URL goes to mapagent.fcgi so this is likely present in all current viewers, but I have only tested in the Fusion web layout.
Exception handler returns the following:
Out of range. - MgHttpQueryMapFeatures.Execute() line 151 file c:\working\build_area\mapguide\2.6.0\x64\mgdev\web\src\httphandler\HttpQueryMapFeatures.cpp - MgDateTime.ToTimeValue() line 859 file c:\working\build_area\mapguide\2.6.0\x64\mgdev\common\foundation\Data/DateTime.cpp
The current workaround is to remove the 'Date' fields from all of our LayerDefinition property mappings.
Change History (5)
comment:1 by , 11 years ago
by , 11 years ago
Attachment: | DatesTest.zip added |
---|
Two polygons with date fields, one in 2014, the other 1942
follow-up: 3 comment:2 by , 11 years ago
I created a small data sample to test with and had to investigate further. In migrating customized code to the updated MapGuide 2.6 engine, I have been working with both a fusion.js and its compiled fusionSF-compressed.js resource. At this point, one is parsing the date only as date (M-D-Y) while the other is attempting to translate to a Date + Timestamp, resulting in the above error on the mapagent.fcgi level.
It appears that the compressed version uses mapagent.fcgi?version=1.0.0, while the uncompiled version uses mapagent.fcgi?version=2.6.0&requestData=12 as the different parameters. It appears the 1.0.0 version returns acceptable Date format (M.D.Y) and has no trouble with pre-1970 entries, while the 2.6.0 version attempts to parse a timestamp out from the date.
Attached is DateTest.zip for your investigation. If off the top of your head you have a tip on correcting the mapagent.fcgi version for my fusionSF-compressed.js queries (compiled from the same js files that feed the non-compiled version 2.6.0 query format), please let me know. Looks like I'll be working that one out tomorrow.
Thank you, Kyel
comment:3 by , 11 years ago
P.S. The lib/MGBroker.js in my /build directory needed to be deleted (I just deleted all the /build folder contents); after that, re-compiling brought the fusionSF-compressed.js script up to date with mapagent.fcgi?version=2.6.0 queries. These are still broken with regard to the pre-1970 dates of course.
comment:4 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Do you have a small sample data set with the problematic date fields?
I know where to look, I just need some data to confirm the problem and verify the fix.