411–420 of 518 posts
Earlier quoted context omitted.
a) You write "1/2" and Excel replaces it with "01. Feb" by default if using de-DE as Locale (just checked it) [This auto replacement is also the basis of the linked article] b) There is no "." on the num-pad for German keyboard layouts, they have a "," the German decimal separator.
If you write 1/2 just put a ' in front of it.
Earlier quoted context omitted.
>2020-08-06 I've just switched to 20200806. Let it be an int and be done with it.
A beautiful property of using ints to represent dates is that you can manipulate them using simple arithmetic. For example, if you want to refer to noon-time on 20200806, you can simply divide the day in two and write it as 10100403. An elegant, DRY solution to a perennial problem.
Final Jeopardy : Trebeck: You know what, how about you just write down a number, any number at all. Could be a 1 or a 2, perhaps 3... and excel you answered; A smiley face emoji, simply stunning. Excel is no longer motivated by the original intention of a spreadsheet, and now caters to the lowest common denominator, a piece of graph paper. As such MS has shifted focus from doing calculation to text and graphics layou…
MSFT did the same thing with Project when they introduced something called "Manually Scheduled Tasks." Project is fundamentally a critical path scheduling tool, or at least was. Task A must finish before Task B, which must complete before Task C. If A is delayed, then that delay pushes B and C out, too. This is what it's FOR, more or less. Manually scheduled tasks don't move. They're set with whatever dates you give…
So? There are tasks like this that simply CANT move, why should a project management tool not have the ability to model that? If you don't like the feature you don't have to use it.
I get that you wouldn't want these fixed dates and if you can just plan and execute your project by yourself, but that is not always the case.
As an example: I had a project where it was really important for us to inspect the Aircraft Type (A321) into which we wanted to install our hardware and software. We where given an opportunity to do so by an airline during the maintenance of one of their A321. This was a fixed date. If we didn't finish our preparations before that maintenance date then we simply would not get this opportunity (or at the very least would have to wait a very very long time for the next opportunity). The Aircraft would simply not wait for us.
Not every task can move and just because you think they should does not make it so. Maybe there is more to Microsoft Project than just YOUR use-case?
Earlier quoted context omitted.
A beautiful property of using ints to represent dates is that you can manipulate them using simple arithmetic. For example, if you want to refer to noon-time on 20200806, you can simply divide the day in two and write it as 10100403. An elegant, DRY solution to a perennial problem.
It’s beautiful. Just mod 7 to find the day of the week.
(I'd love to discuss this further... I'll be back on HN later tonight, sometime around 16834005.)
Excel is an amazing tool. But it also has some significant shortcomings: * A well known tendency to mangle date and gene data under the guide of being 'helpful'. * Easy to making mistakes when cutting and pasting cells. * Difficult to see what is going on in a spreadsheet. * Poor handling of CSV files. Some of these shortcoming are inherent to spreadsheets. Others are specific to Excel, but hard to overcome due to th…
Edit: great call out to 7 days of non consecutive use
Earlier quoted context omitted.
>based on its glorified bugs If someone types MARCH1, DEC1, OCT4, SEPT1 into a column, why should Excel not treat these as dates? Probably 99.999% of users would prefer this auto-understanding. To make users have to then select cell formatting and select date is a terrible UI decision. It's odd to call such a useful feature a bug. >Excel is fundamentally not suited to analysing *omics data But it's excellent for a ma…
> If someone types MARCH1, DEC1, OCT4, SEPT1 into a column, why should Excel not treat these as dates? It should treat these as dates, unless told otherwise. But Excel goes one step further, and throws away the text you originally typed in. That means, if you type "DEC1" into a spreadsheet, see it looks stupid, and change the data type of that cell to "Text", then it's too late, and Excel will show "37226". It has de…
That’s even worse, since a user assumes the cell holds what it shows. Excel, for example, auto completes entries, which is extremely useful for data entry, and for accuracy. If it only held the few characters entered, now it has to repeat exactly the same autocompletes every time it opens, and has to do so even if the data that originally caused the auto complete changes. All this is nearly algrithmically I’m-Seville without changing the document into a history. And now CSV is useless for data transfer.
It’s vastly more sane to change to the data the user meant to enter, show it to the user for confirmation, and save that.
That the 99.99% use case bites the remaining 1 in 10,000 is a perfectly reasonable trade off, done throughout society in uncounted ways.
To people asking, "why do they use Excel?" that's like asking "why must we be subjected to gravity?" The whole world's data ultimately comes from or ends up in an Excel spreadsheet. Sure, we might use other intermediate data storage methods, but in the end it's going to go into some scientist's or some politician's computer, and by golly it's gonna be in Excel. Trying to rally against Excel is like trying to rally ag…
Earlier quoted context omitted.
>based on its glorified bugs If someone types MARCH1, DEC1, OCT4, SEPT1 into a column, why should Excel not treat these as dates? Probably 99.999% of users would prefer this auto-understanding. To make users have to then select cell formatting and select date is a terrible UI decision. It's odd to call such a useful feature a bug. >Excel is fundamentally not suited to analysing *omics data But it's excellent for a ma…
It is shortsighted to call this behavior a "useful feature". It was and is a grave and serious mistake. Automatically converting SEPT1 to a date caused far more damage than the benefit of the fleeting convenience. The damage that this "feature" caused and will keep causing goes far beyond the domain of bioinformatics. Even in bioinformatics things have not been "solved", for the next decade the same gene will have tw…
Earlier quoted context omitted.
I think you've failed to grasp the issue, it's way more than just things I type sadly. It prevents the use csv files for many purposes. That stops excel users interacting with the wider ecosystem of file\data processing systems...
I think the reasoning is people type in "01/02" to actually mean Jan 2nd more often than they import CSVs into Excel. So Microsoft favored one over the other I don't see a problem with that, as it's not undefined behavior – you know exactly how Excel will treat those values