Closed Bug 231280 Opened 21 years ago Closed 20 years ago

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

Categories

(Core :: Printing: Output, defect)

PowerPC
macOS
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: cnst+bmo, Assigned: cnst+bmo)

References

Details

(5 keywords)

Attachments

(2 files, 2 obsolete files)

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:
Keywords: intl, l12y, polish
Do you reproduce this bug with plain Mozilla and/or firebird ?
Target Milestone: --- → Camino0.9
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.
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. 
over to mozilla-land
Assignee: pinkerton → core.printing
Product: Camino → Browser
Target Milestone: Camino0.9 → ---
Version: unspecified → Trunk
Blocks: 103669
Blocks: dateandtime
Summary: Printing procedure should honour date-and-time notation format used in OS → Printing procedure should honour date-and-time notation format used in the OS
Flags: blocking1.7a?
Attached patch proposed patch (obsolete) — Splinter Review
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. :-)
Attached patch proposed patch from CVS (obsolete) — Splinter Review
now I used 
cvs diff -udp8 nsSimplePageSequence.cpp nsSimplePageSequence.h
Attachment #139962 - Attachment is obsolete: true
Attachment #139964 - Flags: review?
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). 
Keywords: qawanted
I have also reproduced this bug on OS X 10.1, so this is not 10.2 specific.
Attachment #139964 - Flags: review? → review?(jshin)
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 212922 has been marked as a duplicate of this bug. ***
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. 

Assignee: core.printing → jshin
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.
Attached patch proposed patchSplinter Review
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.
Assignee: jshin → mureninka
Attachment #139964 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #141190 - Flags: superreview?(blizzard)
Attachment #141190 - Flags: review?(jshin)
Attachment #139964 - Flags: review?(jshin)
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...).
Attachment #141190 - Flags: review?(jshin) → review-
Comment on attachment 141190 [details] [diff] [review]
proposed patch

(Ignore my last comment... the original code uses |time()|, too... ;-( )
Attachment #141190 - Flags: review- → review?(jshin)
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.
Attachment #141190 - Flags: review?(jshin) → review+
looks like this is still lacking sr,  we should pick this up in beta.... trying
to shutdown 1.7a
Flags: blocking1.7a? → blocking1.7a-
Comment on attachment 141190 [details] [diff] [review]
proposed patch

I want to get this patch into 1.7a, please superreview ASAP.
Attachment #141190 - Flags: superreview?(blizzard) → superreview?(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 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.
Attachment #141190 - Flags: superreview?(bzbarsky) → superreview?(roc)
Attachment #141190 - Flags: superreview?(roc) → superreview+
Attachment #141190 - Flags: approval1.7a?
Comment on attachment 141190 [details] [diff] [review]
proposed patch

a=chofmann for 1.7a
Attachment #141190 - Flags: approval1.7a? → approval1.7a+
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.
Attachment #141190 - Flags: approval1.4.2?
Checked in.
Comment on attachment 141190 [details] [diff] [review]
proposed patch

a=mkaply

please get someone to check this in for you ASAP
Attachment #141190 - Flags: approval1.4.2? → approval1.4.2+
checked in on 1.4 branch
Keywords: fixed1.4.2
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? 
Severity: normal → major
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Keywords: qawanted
Resolution: --- → FIXED
Summary: Printing procedure should honour date-and-time notation format used in the OS → Printing procedure should honour Date and Time customisation on Mac OS X
ccing asa for the release note thing.
*** Bug 157497 has been marked as a duplicate of this bug. ***
Depends on: osxtime
*** Bug 156156 has been marked as a duplicate of this bug. ***
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
(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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: