Hi,

seems to be a problem with the default language of your installation.

Set the language of the cells to English US and it should work.

I assume you're not using an English US locale. So the entry is not
recognized as valid date format.

Frank

For now I set this one to worksforme.

If your system locale is set to English US and the problem persist,
fell free to reopen this Issue.

Frank

I am using English US as default language. As it turns out only this
particular value is not recognized as a valid date. 

Just tried this on Mandrake 9.1 and OpenOffice 1.0.2 Calc and it accepts 
4/13/2003 as valid date. This is not the case however on WinXp and OO 1.1RC. 

Hi Eike,

can you have a look at this one please ?

Frank

What should I look at?
I simply don't believe that only the particular value of 4/13/2003
isn't recognized as date but others are, and as long as there is no
further information I can't say anything. Things work perfectly well
if either the system's locale (Windows regional settings in this case)
is set to English-US and the OOo
Tools.Options.LanguageSettings.Languages.LanguageOfLocaleSetting is
set to Default, or
Tools.Options.LanguageSettings.Languages.LanguageOfLocaleSetting is
explicitly set to English-US. The only possibility I could come up
with is the cell being formatted as text, but that wouldn't explain
why other values should work.

So, Dokala6566, what are your settings?

My settings are exactly English-US both in WindowsXP
and OOo.

I experience this on both notebook(DELL Latitude C640
256RAM XP Home) and my home PC(Athlon XP 1600 Nforce1
256RAM XP Pro).

And 4/13/2003 is not recognized as date input but 4/14/2003 entered in
the very same cell is? I have no idea what should cause that, and
nobody else reported that behavior.

Have you tried it yourself? I have been experiencing this since 1.0.3
and could not believe it myself and hoping that it was just my system
setup. But I have tried it already on two machines with similar
results. However I can confirm that this issue does not exist on 1.0.2
under linux.

I've noticed this problem in OOo 1.1 RC in Linux.  I'm downloading RC2
now to see if it is still present.

The locale settings make no difference (I usually use English
Australia, but US has the same problem).

The problem is always in April.

While I can't enter the date directly into the cell, I can enter it
via other means, eg. =date_before+1.  It won't show on the screen
correctly, but it will work for calculation purposes.  If I
double-click on the cell it will change to the correct date, but if I
then go to a different sheet and back again it will have reverted back
to the wrong date.

Here are the dates (wrong) and their numerical equiv (correct):

09/04/2004	38086.0
10/04/2004	38087.0
10/04/2004	38088.0
12/04/2004	38089.0
	
08/04/2005	38450.0
09/04/2005	38451.0
09/04/2005	38452.0
11/04/2005	38453.0
	
14/04/2006	38821.0
15/04/2006	38822.0
15/04/2006	38823.0
17/04/2006	38824.0
	
13/04/2007	39185.0
14/04/2007	39186.0
14/04/2007	39187.0
16/04/2007	39188.0
	
11/04/2008	39549.0
12/04/2008	39550.0
12/04/2008	39551.0
14/04/2008	39552.0
	
10/04/2009	39913.0
11/04/2009	39914.0
11/04/2009	39915.0
13/04/2009	39916.0

Hi pgibbo,

So how was your testing on RC2 and Linux, anything new?

Regards.
dokala

Hi dokala,

The prob is still present in RC2 and RC3.

I don't have an old OO handy, but StarOffice 6.0 is fine, while
StarOffice 6.1beta1 has the problem too.

Paul.

Set oooqa because of visible engagement.

First I have a question:
Is it really so that the correct date input English GB is DD/MM/YYYY
and for English US is MM/DD/YYYY?

If I respect this difference all is ok for me with 1.1RC1 german
version WIN98SE.


Rainer

Rainer,

Yes, English GB date order is DMY.

@Pgibbo: does your example mean that if you enter the serialized date
value and then set the cell's number format to date, a wrong date is
displayed? For example in case of the value 38088?

Yes Eike, that is correct.

While the value displayed is incorrect, all calculations regarding
that cell are correct.

Also, I am able to enter 38088 and convert to a date, however, I
cannot directly enter 11/04/2004 - it formats as text.

When printing it also prints what is on the screen - not the correct
value.

Pgibbo, Dokala,

I tried 4/13/2003 on WinXP and Linux and Solaris with 1.1rc2 and with
different locale settings within OOo, and everything works as
expected. Of course only for locales with MDY order, YMD order as in
en_AU of course doesn't as there is no month 13.

As for the

09/04/2004	38086.0
10/04/2004	38087.0
10/04/2004	38088.0
12/04/2004	38089.0

problem: I tried that (enter numbers and format to date) on both,
WinXP and Linux, using 1.1rc2 with different locales and had no
problem. Also entering 11/04/2004 wasn't a problem at all, not in
en_US and not in en_AU and not in en_GB locale.

So, please, specify:
- your operating system's locale
- the locale of
Tools.Options.LanguageSettings.Language.LanguageOfLocaleSetting
- the locale used in the number format of the cell

Eike,

I don't think this is a locale issue.

If I set my OS locale, OO locale and cell locale to en_AU I am unable
to enter the date 11/4/2004 (DMY).

If I set my OS, OO and cell locale to en_US I am unable to enter the
date 4/11/2004 (MDY).

There is something about a single day in April each year that it
doesn't like.

I have found an interesting pattern, there are either exactly 364 days
(52 wks) or 371 days (53 wks) between the nuisance dates:

DMY
		
11/4/2004	38088	
10/4/2005	38452	364
16/4/2006	38823	371
15/4/2007	39187	364
13/4/2008	39551	364
12/4/2009	39915	364
11/4/2010	40279	364
10/4/2011	40643	364
15/4/2012	41014	371
14/4/2013	41378	364
13/4/2014	41742	364
12/4/2015	42106	364
10/4/2016	42470	364
16/4/2017	42841	371
15/4/2018	43205	364
14/4/2019	43569	364
12/4/2020	43933	364
4/11/2021	44297	364

What is the output of the 'locale' command? Which Linux distribution
and version exactly? Version of glibc? Any ICU library installed in
system (/usr/lib/libicu*)? If so, is one of them called (start OOo
using strace: strace -o outfile -f soffice) or the ones OOo provides?
Any libraries of older OOo/SO versions in the way (in other words:
reachable via LD_LIBRARY_PATH)? Anything else you can tell me that is
different between your's and other systems and could be responsible?
TZ environment variable set? Try to empty it. Timezone selected?

voila...

I removed the /etc/localtime link and now I can enter those dates.

Hope this helps.

Paul.

What was that link pointing to?

Oops... meant to include that in the last post:

/usr/share/zoneinfo/Australia/Perth

As you'd expect, setting TZ:=Australia/Perth also causes the date problem.

Aah, thanks, that was it, now we finally have that reproducible.
Strange enough anyways..

Thank you for cooperating ;-)

Review done.

Fixed on branch cws_srx645_pp1numfor:

unotools/source/i18n/calendarwrapper.cxx  1.9.52.1
i18npool/source/calendar/calendar_gregorian.cxx  1.21.32.1

What a bummer.. a chain reaction of:
TZ:=Australia/Perth leads to a zoneinfo that contains "WST" as time
zone abbreviation. WST is not unique, usage includes Western Standard
Time (Australia) (UTC+08), Western Brazil Standard Time (UTC-04), and
West Samoa Time (UTC-11). Now ICU (International Components for
Unicode, a library we use) maintains its own time zone data, and
probably for the ambiguity reason does not include a direct reference
to WST, but instead looks up a default zone matching the corresponding
zone offset UTC+08, which happens to be Asia/Shanghai. Now that
zoneinfo says that DST (dayligh saving time) starts on the first
Sunday on or after April 10th at 00:00, which explains the observed
52/53 weeks pattern. Strictly spoken, local times between
2003-04-13T00:00:00 and 2003-04-13T01:00:00 do not exist in that time
zone. Our local time setting method in conjunction with the date input
validating routine had a glitch that setting 2003-04-13T00:00:00
resulted in 2003-04-12T23:00:00 and the validating method observed a
difference between input date and resulting date and said "nono". This
could have happened with any time zone switching DST on at 00:00,
which are quite a few, namely in South America, Asia, and Africa.

Reassign to QA.

adjusting resolution to fixed

verified in internal build cws_pp1numfor

Fix will be available in the forthcomming OOo1.1.1

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

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

On (Debian) Linux, OOo 1.9.65 exhibits all the behavior reported in Issue 
17222.

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

Seems like a simple merge should do.  From an earlier comment:
----------------------------------------
Fixed on branch cws_srx645_pp1numfor:

unotools/source/i18n/calendarwrapper.cxx  1.9.52.1
i18npool/source/calendar/calendar_gregorian.cxx  1.21.32.1

The version and target milestone for this bug should probably be updated for
query purposes.

Hi,

this is not a bug of the 1.9.65 Version build by OpenOffice.org. it seems to be
a problem with the Debian build, so file an Issue at Debian.

This is closed as fixed again. Checked with the Macro from Issue 24082 which is
a follow up of this Issue.

Frank

closed fixed

This *IS* a bug in the 1.9.65 build from OpenOffice.org.  I am running the
official OOo_1.9.m65_native_LinuxIntel_install.tar.gz package downloaded from
OpenOffice.org, and installed with alien.

I just ran the referenced test macro from Issue 24082, and got this error:
"2004-3-28 2:0:0.0  NOT ok, should be 2004-3-28 3:0:0.0"

My system timezone setting is HKT (+0800).

Please reopen this bug for further testing.  Thank you.

reopened

Hi Eike,

please have a look.

Frank

set target to some more reasonable value.

As it's fixed for 1.1.x target should be 2.0.

Xcqmichael,

> I just ran the referenced test macro from Issue 24082, and got this error:
> "2004-3-28 2:0:0.0  NOT ok, should be 2004-3-28 3:0:0.0"
> 
> My system timezone setting is HKT (+0800).

You should have noted the comment in that macro, lining out a preliminary
condition that has to be fulfilled:

REM Run in an European locale that uses DST onsetRule 2004-03-28T02:00+1h,
REM with DST being effective on the machine.

HKT doesn't have a DST onsetRule 2004-03-28T02:00+1h and isn't currently in DST
mode, AFAIK it doesn't use DST at all. Without these conditions the macro MUST
fail and the value "2004-3-28 2:0:0.0" is correct here, even if the macro says
it wasn't.

So where else, except by running the macro under false conditions, do you
encounter this issue?

Eike

Reopening issue 39561 and resetting this issue to it's original values to have a
better overview of what was fixed when and in what version. Please, folks, don't
mess around with the target  milestones, thank you.

setenv TZ Australia/Perth
currently (2005-02-09) exhibits this behavior that 2003-04-13 can't be entered
as a date.

On branch cws_srx645_erpp5a:
i18npool/inc/calendar_gregorian.hxx 1.6.146.1
i18npool/source/calendar/calendar_gregorian.cxx 1.21.26.2.22.1

This is the backported fix of issue 39561, which was verified to work with
OOo1.9.x in February/March this year.

NOTE: to reproduce the behavior described above in
------- Additional comments from er Wed Feb 9 09:06:22 -0700 2005 -------
may be problematic, as you'll have to set the system date back to February, for
example, which I didn't do right now in my networked environment => left to QA ;-)

Reassigning to QA.

re-open issue and reassign to oc@openoffice.org

reassign to oc@openoffice.org

reset resolution to FIXED

verified in internal build cws_erpp5a

closed because fix available in OOo1.1.5