NOT reproducible with "LibreOffice 3.5.3.1 (RC1) German UI/Locale [Build-ID: 21cb047-d7e6025-9ba54fc-b4a51a8-f42372b] on German WIN7 Home Premium (64bit), =MONAT('') gives Error message "#NAME" as expected.

Also not reproducible with 3.4.5

So might be Linux reated? But:

In my German  Ubuntu LibO 3.4.4 (VirtualBox) function MONAT() is not translated, but works as expected.

@reporter:
Thank you for your report – unfortunately important information is missing.
May be hints on <http://wiki.documentfoundation.org/BugReport> will help you to find out what information will be useful to reproduce your problem? If you believe that that  is really sophisticated please as for Help on a user mailing list
Please:
- Attach a sample document (not only screenshot) or refer to an existing 
  sample document in an other Bug with a link.
- Contribute a step by step instruction containing every key press and every 
  mouse click how to reproduce your problem (due to example in Bug 43431)
– if possible contribute an instruction how to create a sample document 
  from the scratch
- add information 
  -- concerning your PC 
  -- concerning your OS (Version, Distribution, Language)
  -- concerning your LibO version (with Build ID if it's not a public release)
     and localization (UI language, Locale setting)
  –- Libo settings that might be related to your problems 
    (video hardware acceleration ...)
  -- how you launch LibO and how you opened the sample document
  –- If you can contribute an OOo Issue that might be useful
  -- everything else crossing your mind after you read linked texts

Even  if you can not provide all demanded information, every little new information might bring the breakthrough.

May be you can test <https://www.libreoffice.org/get-help/bug/> for submitting bug reports?

Please report new bugs with initial status UNCONFIRMED

Created attachment 60592 [details]
Testdocument

Sorry for the sloppy report. I just uploaded a document with containing a simple test example. 

Here is some more information on my setup: 
 * Ubuntu 11.10 64 
 * Linux version 3.0.0-17-generic (buildd@yellow) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012
 * LibreOffice 3.4.4 OOO340m1 (Build:402)
 * GNOME Shell 3.2.2.1

LO Language Settings: 
 * User Interface: English (UK) 
 * Locale setting: German (Austria) 
 * Decimal separator key: [x] Same as locale setting (,) 
 * Default currency: EUR 
 * Western: German (Austria) 


I could also reproduced this behaviour on a WinXP vbox running LibreOffice 3.4.6 OOO340m1 (Build: 602) on complete german locale settings.

Hm, I was too busy with the example in the report (I misunderstood), so that I did not read the summary carefully.

[Reproducible] with "LibreOffice 3.5.3.1 (RC1) German UI/Locale [Build-ID: 21cb047-d7e6025-9ba54fc-b4a51a8-f42372b] on German WIN7 Home Premium (64bit):

a) formula in A2: =MONTH(B2) 
b) B2: Empty cell.
c) result unexpectedly number "12"

Also in LibO 3.3.3, OOo 3.3, OOo 1.1.4, so inherited from OOo

Some thoughts:
An empty cell might be seen as "0" by the function, what is the same as "30.12.1899" in normal number format. For that the result would be correct. I tested with Numbers 0 ... 3 in B2, and indeed for 0 and 1 function result is "12", for 3 (1.1.1900) result became "1" for January.
So the calculation is correct, but may be an error message for an empty cell would be more consistent than simply counting it as "0"? I can't see a real bug, many other number operations count empty cells as "0"

I did some additional tests with 'Date()', where also empty cells are counted as "0". 

Bug or feature? I can't tell. Currently I see this one more as a low priority Enhancement Request to improve consistency and comprehensibility than a real bug.

@David:
May be Help should be competed concerning empty cells?

@Kohei:
Can you please check whether MONTH() behaves in accordance with the current general exception rules?

I am tending to mar this one as NOTABUG, everything works correctly, and I have no idea how to improve help or similar. I will ask on
<libreoffice-ux-advise@lists.freedesktop.org>

Hello

(In reply to comment #5)
> I am tending to mar this one as NOTABUG

+1

This case should perhaps be explicitly specified in the help but if so ... to all functions that manipulate dates (DAY, EDATE, YEAR ...)

Regards
Pierre-Yves

It is worth noting that for interop. reasons we probably want MONTH() with a reference to an empty cell to return 1 - and MONTH("") or reference to an empty-string cell to return #VALUE!

HTH.

So I close this one for now.

Thank you for your replies and let me tell you that I understand your argumentation about the calculation being correct. Anyhow I think - in accordance to Michael Meeks' proposal - that MONTH("") or reference to an empty STRING- or empty DATE-cell should return #VALUE!


Let me explain my whole use case for an example (maybe that helps for a better understanding): 

I use calc for accounting and I created a statistic for calculating the expected monthly tax rate by fetching the valuta data from a billing table. 

When I looked at the statistical numbers, I realized that there where already some numbers for December 2012. Digging into it I realized that bills which have not been paid contained no date in the valuta row and where somehow attributed to December. Luckily that did not cause any harm. 

In case of a serious calculations such an error might cost someone a lot of money. 


My point now is, that you cannot tell how users will use the functions provided by calc. Hence, better show an error if data is invalid or incomplete than assume a value that might lead to unexpected results. Therefore I think an error code would be the correct behaviour for empty cells. 

Just my 2 cents, 
Sascha

@Sascha Nemecek
Of course, that is a weighing of competing interests. I see a priority for a  reliable, unique exception handling of all functions. The result is that you will have to check for empty cells in an extra step to avoid miscalculations. That priority will not be changed only because you have an application where you need an extra exception handling. But if your problem is a typical one it can be discussed to extend the old concept. But that is very complex, new behavior may not change results in existing spreadsheets, but offer new capabilities, be in accordance with ODF definitions, ... . Before a developer starts to implement (where he additionally will check all these aspects) it should have been proven that these conditions are fulfilled by a new concept. 

If you have ideas for a more general solution, you should discuss that on <libreoffice-ux-advise@lists.freedesktop.org>