231280 - Printing procedure should honour Date and Time customisation on Mac OS X

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Constantine A. Murenin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7

When I print the page, it is always printed with date-and-time in format like
"1/17/03 4:34 PM" instead of the one specified by the OS. 

This bug was verified with OS 10.2.x (10.2.5, as I can remember), and Camino 0.7.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Ludovic Hirlimann [:Usul]]

Do you reproduce this bug with plain Mozilla and/or firebird ?

Comment 2

[Constantine A. Murenin]

Yes, bug is reproducible with Mozilla 1.6 and Firebird 0.7.1. 
Must be a hard-coded string, since in the bookmarks manager and Mail/News
everything appears to be OK. OS is 10.2.6. 

Steps to Reproduce:
1. Change your default settings for date-and-time in the OS X. 
2. Open any Mozilla and print any page (or use Print Preview). 

Actual Results:
Date and Time format is incorrect.

This problem is not reproducible on win32.

Comment 3

[Constantine A. Murenin]

Why am I not being able to change the Target Milestone? It needs to be changed
in order to move the bug to a different Product category. 

Please, move the bug to Product: Browser. 

Comment 4

[Mike Pinkerton (not reading bugmail)]

over to mozilla-land

Comment 5

[Constantine A. Murenin]

Attachment: proposed patch

This is a patch I've made based on my survey of similar implementation in
<http://lxr.mozilla.org/mozilla/source/mailnews/base/src/nsMsgDBView.cpp#640>.
I have tested this on FreeBSD with Mozilla 1.4 and it does not break anything.
I do not have an OS X with a compiler, so I am not able to test it on Mac. If
anyone can compile it for OS X, then I can test it. 

P.S. This is my first patch for Mozilla, so any comments are welcomed. :-)

Comment 6

[Constantine A. Murenin]

Attachment: proposed patch from CVS

now I used 
cvs diff -udp8 nsSimplePageSequence.cpp nsSimplePageSequence.h

Comment 7

[Constantine A. Murenin]

Reproducible: Always

Steps to Reproduce:
1. Open System Prefs, choose International, change date format to be
Year/Month/Day (assuming, that the default format is not Year/Month/Day for your
locale). 
2. Open any Mozilla, print any page (or use print preview). 

Actual Results: 
The printed date is not in format YYYY-MM-DD. 

Expected Results: 
The printed date is in format YYYY-MM-DD. 

Verified on OS X 10.2.6 with all Mozilla browsers (App Suite 1.6, Firebird 0.7,
Camino 0.7).

P.S. The date in MailNews IS correct, so I borrowed the code from MailNews to
the printing procedure (see patch from previous comment). 

Comment 8

[Constantine A. Murenin]

Attachment: Mac OS X 10.2.6 and Mozilla 1.6: Date and Time problems

I have also reproduced this bug on OS X 10.1, so this is not 10.2 specific.

Comment 9

[Boris Zbarsky [:bzbarsky]]

*** Bug 212922 has been marked as a duplicate of this bug. ***

Comment 10

[Jungshik Shin]

I'm sorry I haven't noticed this bug. Somehow, I haven' received bug mails from
this bug. 

It seems like we need to overhaul Mac locale code. Actually, intl/locale as a
whole needs quite a lot of work. I've done some clean-up last fall. 
I'll try to comment on your patch later. 

Comment 11

[Dave Miller [:justdave]]

Comment on attachment 139964 [details] [diff] [review]
proposed patch from CVS

applies with fuzz and offsets (but no conflicts) to cvs tip, but it works.  I'm
not a good person to vouch for code correctness though.

Comment 12

[Constantine A. Murenin]

Attachment: proposed patch

This is the same patch as the previous one, except that it fixes the spelling
mistake (formatter with one T), which was taken from nsMsgDBView.cpp. Also
fixes some indentation issues.

Comment 13

[Roland Mainz]

Comment on attachment 141190 [details] [diff] [review]
proposed patch

> +
> +    nsAutoString > formattedDateString;
> +    time_t ltime;
> +    time( &ltime );

I suggest to use the matching NSPR functions here - see
nsprpub/pr/include/prtime.h for the matching functions (|time()| should work in
theory on all Unix platforms... but remember we have to support stuff like VMS,
too...).

Comment 14

[Roland Mainz]

Comment on attachment 141190 [details] [diff] [review]
proposed patch

(Ignore my last comment... the original code uses |time()|, too... ;-( )

Comment 15

[Jungshik Shin]

Comment on attachment 141190 [details] [diff] [review]
proposed patch

r=jshin

Both the current code and your code should work the same way, but somehow they
don't (according to you). Anyway, your patch will cut down the code size, which
is good.

Comment 16

[chris hofmann]

looks like this is still lacking sr,  we should pick this up in beta.... trying
to shutdown 1.7a

Comment 17

[Constantine A. Murenin]

Comment on attachment 141190 [details] [diff] [review]
proposed patch

I want to get this patch into 1.7a, please superreview ASAP.

Comment 18

[Boris Zbarsky [:bzbarsky]]

If you need an sr asap, please do not ask me.  I'm swamped with non-mozilla
things right now and unable to do reviews for the foreseeable future.

Comment 19

[Constantine A. Murenin]

Comment on attachment 141190 [details] [diff] [review]
proposed patch

roc, I want to get this small patch for big improvement into 1.7a, please
superreview ASAP.

Comment 20

[chris hofmann]

Comment on attachment 141190 [details] [diff] [review]
proposed patch

a=chofmann for 1.7a

Comment 21

[Boris Zbarsky [:bzbarsky]]

So as far as why this happens....  If you look at
http://lxr.mozilla.org/seamonkey/source/intl/locale/src/mac/nsDateTimeFormatMac.cpp#280
you see that if we are not using the default locale we do this
GetPlatformLocale() thing.  Then back in nsDateTimeFormatMac::FormatTMTime at
http://lxr.mozilla.org/seamonkey/source/intl/locale/src/mac/nsDateTimeFormatMac.cpp#390
we set some pointers to null if using the default locale and not otherwise. 
Then we pass those to DateString().

So either GetPlatformLocale() is confused or the GetItl0Resource/GetItl1Resource
functions are confused, is my guess.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Checked in.

Comment 23

[Mike Kaply [:mkaply]]

Comment on attachment 141190 [details] [diff] [review]
proposed patch

a=mkaply

please get someone to check this in for you ASAP

Comment 24

[Christian :Biesinger (don't email me, ping me on IRC)]

checked in on 1.4 branch

Comment 25

[Constantine A. Murenin]

Verified on Mac OS X 10.2.6 with the latest FireFox 2004-02-16 and Camino
2004-02-16. Marking this bug FIXED. 

All builds after and including 2004-02-16 should have this fix. 


As this bug affects user experience in such a way that timestamps produced are
in a wrong format on permanent media (paper), I am changing Severity to Major. 

Could this bug be shown in the What's New section of the Release Notes? 

Comment 26

[Boris Zbarsky [:bzbarsky]]

ccing asa for the release note thing.

Comment 27

[Constantine A. Murenin]

*** Bug 157497 has been marked as a duplicate of this bug. ***

Comment 28

[Constantine A. Murenin]

*** Bug 156156 has been marked as a duplicate of this bug. ***

Comment 29

[Eric Maryniak]

With a recent yum updated Mozilla:

    Mozilla 1.4.1
    Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114
    under KDE 3.1.4-4

the issue was again resolved, with my previously mentioned 'hack'
(setting LC_TIME to the 'odd' en_DK, prior to calling mozilla):

    LC_TIME=en_DK mozilla http://some/url.html

Comment 30

[Constantine A. Murenin]

(In reply to comment #29)
> the issue was again resolved, with my previously mentioned 'hack'
> (setting LC_TIME to the 'odd' en_DK, prior to calling mozilla):

Eric, this bug is not reproducible on linux (as far as I am aware of). You just
need to set your locale to the appropriate value used in your country, and
everything will work as desired. 

Your hack does not match description of this bug; please comment in bug #140814,
which might be the place for your issues. If you have en-US as your default
locale (hence you have a dodgy date format), then you should complain to your OS
vendor, since it is not mozilla issue.