Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Append a .0 to numbers in the range [1900,9999] if returning XML data to Excel. #116

Merged
merged 4 commits into from
Mar 7, 2013

Conversation

cvpcs
Copy link
Contributor

@cvpcs cvpcs commented Mar 3, 2013

There is a bug in Microsoft Excel 2013's FILTERXML function, which causes
it to attempt to coerce numbers between [1900,9999] as dates. It then
returns their serial value (number of days since Jan 1st, 1900). This
coersion happens at a point where the user is unable to prevent it and
there is no known work around.

Luckily, when Excel 2013 requests data using its WEBSERVICE function, it
sets its user agent to Excel/15.0. We can thus check if Excel is downloading
data and if so, append a .0 to the end of numbers within that range. This
will prevent date coersion, and doesn't negatively impact the data, since
in Excel all numbers are floating points when doing calculations anyway.

cvpcs added 4 commits March 3, 2013 12:31
…2013

There is a bug in Microsoft Excel 2013's FILTERXML function, which causes
it to attempt to coerce numbers between [1900,9999] as dates. It then
returns their serial value (number of days since Jan 1st, 1900). This
coersion happens at a point where the user is unable to prevent it and
there is no known work around.

Luckily, when Excel 2013 requests data using its WEBSERVICE function, it
sets its user agent to Excel/15.0. We can thus check if Excel is downloading
data and if so, append a .0 to the end of numbers within that range. This
will prevent date coersion, and doesn't negatively impact the data, since
in Excel all numbers are floating points when doing calculations anyway.
@cvpcs
Copy link
Contributor Author

cvpcs commented Mar 6, 2013

I updated this to use a GET variable check instead of the user agent string. This should play nicer with your reverse-proxy, and actually will likely be more performant since it's just checking if a variable exists instead of a regex.

@rubensayshi rubensayshi merged commit cdef858 into rubensayshi:master Mar 7, 2013
@mercutiodesign
Copy link
Contributor

I think the new variable / parameter should be documented in the API specification so that others can profit from this as well.

@rubensayshi
Copy link
Owner

yea, I need to work on the docs, it doesnt even have the xml atm xD

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants