Issue 100936

Found a work around

To stop a date being mangled in a table put a full stop in front of it, then
colour it white.  pathetic I know, but so is the way that Writer handles dates.

Not a P1.
Not a bug: you may switch the number recognition off or format the cell the way
you like before typing.

Please also next time, choose your exact OOo version in the list, and describe
more precisely what you mean with "mangled".

closed

NO, 

I care deeply about Open Office and FOSS, this is not a simple 'read the manual'
issue

My machine is set to ISO dates, 
ON a fresh install of Writer (v3.0.0m9) I create a blank document
In that document I write the date 2008-08-30
it is fine,
I create a blank table, 
Within the table i write the date 2008-08-30
When I leave the table the program reformats the date an unrecognisable format
with slashes (perhaps american?) and the original date IS LOST
The same Error occurs if I use a table and (this is very common) I need to input
a section number, for example 2.5.8
On leaving the cell the number is mangled again - and is displayed as a (perhaps
american?) date?
My point is not that this 'feature' can be turned off, the point is why is it
there in the first place? New users are appalled by unexplained behaviour like
this.  The 'feature' should either be removed, or at least, disabled by default.

This is a separate issue to the poor date handling in OO and calc in particular.


Marc Sinclair

Changing summary and issue type according to reporter's last comments.


Reassigned

*** Issue 101357 has been marked as a duplicate of this issue. ***

It is a bug since it is an undocumented functionality. Why is "number
recognition" turned "on" in tables and "off" in things that are not tables? What
is the logic behind this? More importantly, where is this documented so that I,
Joe User, knows why it is this way?


I spent hours trying to figure out where in "Autocorrect" my version numbers
were "automagically" translated to dates (1.1 --> 01/01/08 ?!?) until I finally
found a "workaround" which happens to be unrelated to Autocorrect (hint: all
"magic" automatic text conversion stuff should *be* in Autocorrect, logically
speaking). All numbers following the format X.Y where X < 13 are translated to
dates.

To reproduce, create a blank table and insert in each cell successive dotted
numbers.

I should add that this issue still affects OpenOffice.org 3.1.0 (OOO310m11
Build:9399).

*** Issue 100936 has been confirmed by votes. ***

this is not a problem of autocerrection

Please look at "Tools -Options -> OpenOffice.org Writer - Tables"

there you'll find "Number Reconition"

 

Please look at "Tools -Options -> OpenOffice.org Writer - Tables"
there you'll find "Number Reconition"

--> yes, we found that; buy why is it "ON" by default? There is nowhere in the
documentation that states "numbers entered in tables will be automagically
converted to dates, and you can turn this ''feature'' off by doing the above."

When having a problem with text that changes by itself, the average user will
generally suspect autocorrection. It is confusing that there are several places
to activate or desactivate "things that change text automatically".

Indeed, the issue can be solved by turning off the "Tools / Options /
OpenOffice.org Writer / Tables / Number Recognition" setting. The problems are:

1. "Number recognition" does not seem associated with date recognition. Could be
named "Date and number recognition", or a separate option for dates could be added.

2. Date recognition could be turned off by default. I spent a lot of time
fighting with this problem. The most important thing is that date format change
cannot be called "expected behavior": if I write "2009-09-18", I really mean I
want it that way, and it is really frustrating to see it changed to "09/18/09".

It's one thing to detect a number - e.g. entering 1.5 could, if some default was
set, be changed to 1.500 or whatever.

Dates are a different issue completely. Entering the month's name and having it
changed to the short date format is completely infuriating. 

And undo doesn't have a separate step for this, so undoing it simply undoes the
change of format which is then redone as soon as you leave the cell. RUBBISH! 

For me, this is probably the most annoying thing about OO I meet on a daily basis.

this is a question of support. discuss it at users@openoffice.org or the
corresponding mailinglist in your language

-> closed

If you guys consider this a "support" issue, I will consider going back to
Microsoft Office.

Cheers,

mathieu

I agree with maathieu, this is not a support issue. Please re-read comments
carefully, e.g., these:

maathieu Wed Jul 22 13:16:26 +0000 2009
kuzmiigo Fri Sep 18 10:20:05 +0000 2009
blueglow Tue Oct 20 10:34:32 +0000 2009

I hope this issue can be solved as it is really annoying for a novice OOo user.

Sorry I just tried this in a fresh install 
3.1.1
OOO310m19(build9420)

The PC desktop is set to ISO dates, so 2009-11-12 is a correct date format and
is accepted and used by all (my) programs.

in a blank document insert 2009-11-12 this is fine

add a table, in one of the cells insert 2009-11-12
on leaving the cell, the date is mangled into an unknown format including slashes!!!

There is no obvious way of formatting the cell for dates, and if there were,
shouldn't it use the machine setting?

This bug causes any dates to be input or pasted into a writer table to be
mangled and the data lost.

Many Many people, me included, use writer for manuals, the standard way of
formatting is the simple 1.2.3 heading

A manual will consist of many sections which may or may not be formatted using
tables.  If a section number is inserted in to a table it also is mangled into
an unknown format.

The point is not that this behaviour may be turned of, but why it exists in the
first place, and why it is enabled by default.

You may believe that you are cleaning up unimportant issues by labelling them as
support, but it is the likes of ME who has to pick up the pieces of this shoddy
coding.

@marcsinclair: you are talking about bugs in this function (date not formatted
in system locale) and propose as fix to switch it off: fix not accepted.

If the function doesn't work *as it should*, file a (another) detailed issue
about this mentioning your system language and a step-by-step description of
what you do get and expect.

We don't fix bugs by switching buggy functions off!

Now to the meaning of this function: quickly type dates in tables "like" in
Calc. (BTW: the AutoFormatting "March 09" -> "01.03.09" is the same as in Calc)

Now to the default: we usually switch features we implement by default ON in
order them to be used.

A good software should be yes so intuitive that it has no disturbing item and if
then it should be obvious where to switch them ON/OFF.
Yes it should but it's not always possible and what disturbs some people, some
other like it...

So now there are 3 possibilities:
- You learn how to use this function
- you know how switch it off and do so.
- you report real bugs (meaning not "I don't like this function, switch it
off!") and enhancements.

closed

*** Issue 107665 has been marked as a duplicate of this issue. ***

I would like to add another feather of "seriously annoyed user"-weight to this
issue.  I forget the exact details, but I suffered the "number recognition"
curse as well.  Personally, I find it ridiculous that Calc doesn't even TELL the
user what's happening.  I would recommend that rather than turning it off
completely, that instead a notification pop up the first time number recognition
is used by the program each session.  Obviously, there are plenty of
alternatives, but leaving it simply turned on is likely to piss tons of people
off, and might cause a business or government entity evaluating the software to
simply drop it if they discover that the software is doing things they don't
expect it to do.

I believe that some sort of compromise is possible between user experience and
feature-richness.  I understand someone will undoubtedly have worked hard to
make the number recognition feature available, and I have no doubt that there
are people that find it useful.  At the same time, it was nearly a show-stopper
for me when I had a project due soon for a class.  If the bug (and I WILL call
it that; were a programmer using an IDE that behaved in this way, changing
intentionally-entered information without asking or notifying the programmer of
what was going on or where to turn the annoying behavior off, the programmer
would curse loudly and repeatedly and declare "the feature" to be a bug) can
nearly devastate a simple student's experience with the software, then it would
undoubtedly set any other large-scale users, such as a business or government
entity or university, into a serious tizzy.  Large scale users might become
large-scale donors.  Large-scale donors are your friend.  "Features" that might
chase away large-scale donors should be modified such that they do not have such
a potential.  This doesn't mean the feature should go away, or even that the
feature should be turned off by default.  It simply means that the user
experience should be enriched with information telling the user why it is that
their information is being changed, and how to stop it from happening.

Beyond this, I have an opinion on how to handle such complaints in the future. 
Remember that as someone handling bugs for a large-scale product with many
simple end-users, you are often the first person related to the project that
users with an issue will communicate with.  If you come across as though you're
saying, "We're right, and we don't care about your problems, go away," or, "If
you don't know every little detail about the software, you're too stupid to be
using it," then you'll chase users away and pollute the community in general.  I
understand that no one here actually said anything of that nature, but some
might construe certain posts as such.  I also understand that it may sound like
I'm telling you how to do your job.  To some extent, I suppose I am, but please
understand that I'm trying to be polite about it.  I understand that you're
busy, and have lots of bugs to triage and little time, and things that you'd
like to do with your life other than deal with whiny users.  However, it greatly
enhances the user's experience when you show some level of sympathy to their
plight, such as noting that you've experienced such frustrations with other
software before and are willing to help the user fix the issue short-term (in
this instance, finding the checkbox to turn the behavior/feature off), and are
also willing to work with the user to look into long-term solutions and are
willing, at least a little, to investigate whether or not anything in the
project itself needs to be changed.  In this case, when the user suggested that
the feature be turned off by default, it would be far more diplomatic to say
"Disabling the feature by default is an unacceptable solution.  Would you be
willing to work with us to help find an alternative acceptable to users?"

Also, immediately closing a bug makes it look like the entire team, or at least
the specific responders, don't care about user frustrations at all.

Remember, one of the purposes of Open-Source Software, as an idea, is to make
GOOD SOFTWARE.  Good software doesn't just have good features that do cool
things, it has good features that do cool things when the user wants, how the
user wants.  Good software doesn't just have the best algorithms, it has the
best user experience.

Also, if this isn't the proper place to report such an issue, for example if
user-experience issues are supposed to go to some other bug-tracker or
suggestion box, then don't just tell the bug-reporting user to go elsewhere
(that sounds like you're telling them to four-letter-word off, by the way), tell
them exactly where they need to go (a link helps!) and give advice about the
procedure they need to follow.

Anyway, sorry for the long post.  I used to work retail, and based on what I've
seen having to handle customer service issues, the kind of behavior displayed
here would shortly result in cardboard signs with phrases like "Will work for
food" printed on them...

This feature has cost me a lot of hours and i really don't see how this is ever
going to help anyone. 

If someone types in a certain data format it should stay like that. Point.
The fancy thing you can do is to create the possibility to change it according
to your wishes an thus add it to the cell formatting.

Most obnoxious is that it is impossible to find what is causing this. it is nit
in autocorrection. it is not a field and there is nothing about a date format in
the menu or the help.

So please at least add this to the documentation and if the fancy stuff is not
working then switch it off by default because it is incomplete and undocumented.

I agree with the points above. I was unable to disable this without resorting to
a Google search (which turned up this closed bug). This must either be default
disabled or trigger a pop-up on the first table entry.

I also spent several hours with this issue. 

Why was this marked as invalid? 

The "Number formatting" under tables is not a logical place to look for anyone
having this issue with writer. Even if it's not a bug, it is unquestionably a
poor design choice. I agree with others that when a feature is so aggressive as
to get in the way of normal use (and this one absolutely does), it should be
disabled by default.

Also, with calc values which aren't even supposed to be dates get magically
changed into dates. This may be appropriate if the cell is marked as "Date", but
otherwise calc would do better to leave it alone.

*** Issue 111089 has been marked as a duplicate of this issue. ***

From reading this comments I seem to find that SOME of developers of OpenOffice
are arrogant or ignorant.  Note that I'm sure MOST developers on this project
are not arrogant at all and are superb at what they do.  So please don't get
offended if you are one of the good guys or gals.

I want to get this point across though: software engineers don't necessarily
make good designers!!!!  Some do sure... but a lot can't design!  The reason
being if someone is ULTRA technical then they design for ultra technical
people... this is a fail!

This is DEFINITELY a bug, not a software bug agreed, but it IS a design bug. 
For those that can't see this are just bad designers.  Sorry if that's hard to
swallow but that's a fact.  I have noticed lot's of bug reports for OpenOffice
where the whole 'Not a bug' comes in to play.

The designers (not the engineers) need to start being a bit more honest about
usability.  Good design is easy, well at least for me.

All user interfaces from microwaves, to cars, to MP3 players to mobile phones
should be intuitive top most people for most functionality WITHOUT having to
read the manual.  If I have to read a manual to use a DVD fail it means the
designers have failed... most DVD players ARE intuitive but some are badly
designed (Yes I said badly DESIGNED).

It worries me that people are so retarded at basic design skills.  Of course my
advice will be ignored and people will keep being bad at what they do lol.

Software engineers should stick to writing code NOT designing software (unless
they happen to be skilled and TRAINED in design - YES you need to be trained to
design... to think otherwise is extremely arrogant or ignorant!)  No offence
guys!  If everyone knew their limits of expertise we'd be living in a much
better world.  I DO have expertise on good design and it's a fact that this
issue is a design flaw.  It is NOT up for debate in my book, it's a blatant fact.

Here's the test.  Ask 20 random users of OpenOffice (from a cross-section of
different types of user) and ask them to reproduce this bug.  Most people will
find it rather bizarre... this IS a design flaw.

The phrase 'unusual behaviour' EQUALS 'bad design'.  End of.

I am starting to get really annoyed at poor design in this world... it's not
that hard come on!

I invite you all to read
http://blogs.sun.com/GullFOSS/entry/just_10_more_days

and to actively contribute to the current subproject "Better Defaults".
When the Wiki database will work again (we apparently have an outage), you will
find at
http://wiki.services.openoffice.org/wiki/User_Experience/Improving_OOo_Default_Settings
that this enhancement is already listed.

*** Issue 118082 has been marked as a duplicate of this issue. ***

(In reply to comment #29)
> *** Bug 118082 has been marked as a duplicate of this bug. ***
It certainly seems to be a duplicate, however I have since found that the bug doesn't exist in LibreOffice 3.3 running on SUSE11.4 but does exist in OpenOffice 3.3 running on Windows. Whether the bug is Windows dependent or whether a fix has been introdeuced by the LibreOffice crowd, I don't know yet.

Also, the proposed fix is Not a fix. The propsal is to turn off the Writer / Tables / Number Recognition "feature". 

In Writer Version 3.3 there is no Writer / Tables / Number Recognition menu item. If the "feature" is reached by some means other than the menu, please explain how. 

As the proposed fix is not valid, the bug should not be marked closed.

Another vote to please disable number recognition by default. 

This has bugged me quite frequently, and I never knew exactly what was going on until I had to work on this big table this past weekend, which contained many partial dates, was bugged dozens of times by the date changing at will; so I hit the internet and started searching for answers. 

It is completely unexpected behavior that OO will replace a date that I typed into a date that I didn't type. 

I very often use tables to keep things easily aligned & spaced out in headings etc. and I also often work on international documents; so I know a thing or two about keeping dates in check and sometimes needing to change the language settings. 

But, when I'm working on a local document and type 05/2002; OO should never change it to 05/01/02 nor change it into any other date format; as I did not specify the actual day for reason that it was either unknown or irrelevant. 

05/01/02 could be Jan 2nd 2005 or May 1st 2002 or the 5th of Jan 2002.

I just voted in favour of this issue. The number recognition assumes that anything in the format "#:##" is a time, and converts it to "##:##:##" (presumably hours:minutes:seconds). I have many times entered information that happens to LOOK like a time, but is, in fact, NOT a time. Converting "5:30" to "05:30:00" is just wrong. And, as has been pointed out several times, the option is not very well defined.

I would also add that if I type in "5:30", and the program changes it to "05:30:00" and I go back and re-edit it to "5:30", the program should take that as a strong hint that I do NOT want it to change what I entered.

Hello,

This is issue is NOT minor,
it is really MADDENING.
I need to have the date in a certain way
and each time I am in Writer in a table 
the system keeps changing the date to a format that I don't want.

Can you understand that users need to control what they do and not have the system control them ?

I didn't remember why I had stopped using OOWriter and switched back to Word2010,
now I know. I just can't work like that.

I am in the process of using OOWriter again, but getting to the limit of my patience. 

Solving such issues is just showing respect to the users. User interface issues are by essence not minor.

Thanks for listening,

F. Fernandez, Geneva, Switzerland

This issue continues to rear its ugly little head in Ooo 4.1.1
This is a design bug which has the potential to halt the penetration of Open Office in most organizations.  
I ask the programmers to take design issues like this seriously because little issues like this have a way of souring the user experience, and if that user happens to be someone who is making a decision about what their organization is going to use to edit documents, they are likely to choose to spend money on some software package to do the job rather than deal with noobs complaining about this bug repeatedly. Look at it this way, if there are people are using stupid little annoyances like this as an excuse for choosing to use something else rather than use the software you've been painstakingly working on for who knows how long, then you're basically wasting your time working on this software in the first place. Fixing this and similar design bugs will get more people using your software and make your time and effort more relevant.