Alternatively PMs read all the feedback sent via the feedback UI on Excel web and desktop so you can use that instead if you prefer.
What this means is we'd need to go from just requiring a laptop and a copy of the spreadsheet to requiring redundant internet connections and validating Microsoft's backend meet the regulator's requirements. I'm pretty sure that would unfortunately rule out using it.
The companies I work for while consulting (mainly financial and health organizations) have been very cautious about any company or PII data going to these A.I. programs, and the cloud in general, and are looking to make their own local run generative A.I. LLMs for their employees to use.
By it's very nature these Excel documents will be filled with company data, so I can imagine these companies would also be a bit cautious sending those calculations to the cloud, especially if they can't control the flow of data from their I.T. departments via web applications.
But I'm just a software engineer at the end of the day, and don't professionally use Excel all that much right now (if anything I use it much more for my hobby of board game design). So I can't speak with too much authority on the matter. Just my observations.
This is exactly what I see when talking to users about xlwings: it needs to run on their end, behind their firewall, in exactly the cloud they have picked (AWS, GCP, Azure).
I know it's old fashioned to want local software to only change things on my local file system, but if I didn't want that paradigm, I'd just use Google Docs.
The disruption from even a few outages is enough to prefer to run things locally. We had issues with people unable to sign into Excel and everyone went mad (rightly so, as Excel was running locally not 365 but it blocked usage)
And on top of that, there are scenarios where you'd want to process substantial amounts of data that would be prohibitive to upload, process and return the results, where locally handling it would take way less time.
It's about the recurring payments, the lock-in, and ultimately literally having the knowledge and business processes of the world economy on their own computers. If this is true, the reason why it is important to run data and scripts locally should be clear, and so is the motivation of your PMs to actively combat any such things.
But if you get a summary in your inbox and show it to your PMs let us know how that goes down.
Idk, it's really up to Microsoft's business units. Office could be the loss leader to get cloud business, but it could be the other way too. Either way, I would hazard that they want people to actually use this integration feature.
Python -> Excel sounds great.
Cloud Python -> Cloud Excel sounds too much like a privacy and security disaster waiting to happen.
[1] https://wiki.python.org/moin/PythonSoftwareFoundationLicense...
Can you please just add a button - "unmess this document"? The number of man-hours I've wasted re-creating documents is countless. My job is to do other things not fix excel documents.
If you paste your date string in a more standard date format like 2023-08-220 9:08:11, then Excel will correctly infer that it is a date. However, you seem to be saying that Excel should handle ANY numerical strings that way if they are long enough to express a date or datetime, which, while it might make your particular workflow easier (or it might not), it would really mess with people's ability to use Excel with large numerical values...
I can provide instructions on how to do this until the cows come home. I will still get files with these issues. Is that not obvious?
Do you really think I want to examine _tens of thousands of rows_ in documents that are 100 cells wide looking for a single exponent value!?!?!?! Is that really what you're suggesting as a fix here?
If you want Excel to interpret strings as dates, use a more common date representation such as iso8601
Numbers in Excel only maintain 15 digits of precision. Leading zeros are also truncated. If you haven’t experienced this you are lucky (or just didn’t notice) but it is real.
> If you want Excel to interpret strings as dates, use a more common date representation such as iso8601
You don’t always control the upstream system. Your response can be considered rude because it implies you think you know more than the person expressing pain. This is especially insulting with such a widely known problem in Excel.
This behavior burned me with billing system IDs. Logically they are strings, we would never do math on them. For performance they were implemented as BIGINTs in the DB. Excel truncates everything after the 15th digit. Our IDs were all over 20. So accounting couldn’t reconcile our reports with the billing system.
That's a problem, sure, but not the one sixothree is complaining about.
> The problem isn’t assuming a display format for data
Your problem might not be, but that’s exactly the problem sixothree is complaining about that the post you are responding to addresses, so while your post references a valid complaint, it is a complete non-sequitur as a response.
Because they have been dealing with the same bug for 10 years, I thought that was obvious.
I don’t believe you’ve been doing it that long and haven't found the fix.
Apply appropriate formatting if you have long strings of numeric digits [as long as they can’t have leading zeroes] that you want stored as numbers but displayed without scientific notation. (Not the best choice for what is semantically a date, in your case, but...that’s a whole bigger issue and, well, babysteps.) You don't have to look at anything, just do it for the ranges where that is the kind of data:
https://help.godatafeed.com/hc/en-us/articles/360049916591-H...
In the past I have added an apostrophe to the front of any integer that should be displayed as a string. Excel will not display that leading single apostrophe. It of course taints that data forever but I consider “Exported to Excel” a terminal state anyway.
It's asinine Excel has this behavior with any large number. Try to work with a list of EAN/UPC codes... it'll wreck every single one every single time, unless you take significant care to guard against it via formatting, special characters that trick it into using a string, etc. Try working with a spreadsheet full of database id's... same thing. It's asinine.
By the very nature of Excel, large numbers belong as-is... ie. you're studying something and need the values. Approximations (what scientific notation gives you in the best case) are an exception to what people need nearly every time.
Okay, so set formats appropriate to what is useful for your data.
Defaults don't cover all cases, otherwise there would be no non-default options.
> It's asinine Excel has this behavior with any large number. Try to work with a list of EAN/UPC codes...
Codes aren’t numbers they are strings, even if the code is a sequence of digits. They should be formatted as text. For actual numbers that shouldn't be displayed in scientific missions, the appropriate numeric format does that.
> it'll wreck every single one every single time
If its any code that can be safely stored as a number, it won't wreck it. It’ll just look bad until its fixed. If it, say, has significant leading zerores, yes, it’ll wreck it, because excel defaults to dealing with numbers, not text, and there is a difference between text made up of digits and actual numbers.
> unless you take significant care to guard against it via formatting, special characters that trick it into using a string, etc
Knowing the shape of data you are entering and selecting a column and applying an appropriate format (including “text” as an option) before you enter any data (usually, to a whole column) isn’t that arduous.
Your offered work-arounds only apply in a very narrow workflow. I work with Excel nearly every day, all kinds of files (CSV, TXT, XLS/X, etc). There's so many ways this issue can bite you unexpectedly - causing you to save and permanently destroy data.
If I type/paste/import/download/whatever `01234567890987654321` into a cell, 100% of the time I do not want `1.23+E18`. I don't want to even see that, I want to see the original value I entered.
It's asinine.
Excel may be the most used Office Suite app, but it's by far the most painful to use. The Excel Team has a long history of justifying downright perplexing behavior. Remember when Excel was the only Office app that didn't support Snap-To back in the Win Vista/7 days? Joel had a long-winded explanation that boiled down to "just cause"... it was perplexing even at the time. It really makes one wonder how bad the rat nest of a codebase Excel is.
"There's ways around our astonishing default behavior so just deal with it". That's not a great answer.
This burned me frequently when I was generating tax audit reports for accounting. The billing system IDs were all BIGINTs but had over 20 digits.
If I type "2023-08-22" into a cell in Excel I see "8/22/23" in the cell and "8/22/2023" as the value.
None of the ISO8601 formats I've tried are recognized. "2023-08-22", "2023-08-22T01:38:22Z", "20230822T013822Z" are all valid ISO8601, but Excel treats them as unformatted text. Inputs with slashes are instantly recognized as a date.
If it works for you, it may be a locale thing. But getting away from that is the whole point of ISO8601.
However, to my eyes, and probably most people, 20230822090811 does not look like a "date string", it's a number. It's correct to display it as scientific notation if it's too many digits to fit into the width of a cell. Please let's not encourage them to interpret more things as dates and randomly break people's workflows.
Excel should preserve all the digits you enter in the cell even if it doesn't display them, though. That has nothing to do with dates. It's a problem with things like product numbers or keys that can end up with many digits.
Pessimist: The glass is half empty.
Excel: The glass is January 2nd.
There’s a world of difference between having a file stored locally in Windows and one purposefully uploaded to Office 365 for data analysis.
(Although, I'm guessing the reason they did it this way is so they could keep the execution model the same for Excel on the web? It's always running on the external service vs sometimes running locally and sometimes running externally.)
With that API, it won't matter whether you want Python, Ruby, Lua, whatever, for your scripting language.
This is nice, but it welds a specific version of Python inside Excel and makes it a gigantic PITA to use your normal development tools on your Python code.
How out of touch with the real world is the Excel team?
It is horrible..
The amount of lost productivity because "report file" cannot easily connect to "source 1, 2, 3" is very high.
In theory you can do it, but it plain does not work in shared sheets.
Does the problem persist if you ensure the other source files are open before opening "report file"?
If opening the files in the right order solves it, then it may be possible to script this in Excel or in an Excel add-in (optionally, signed).