Closed Bug 220850 Opened 22 years ago Closed 21 years ago

Mail message timestamp adjustments for local time seems to be broken

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: SGwylan, Assigned: jhpedemonte)

References

(
URL
)

Details

Attachments

(1 file)

test.c compiled to make time zone check
13.88 KB, application/octet-stream
Details
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.5) Gecko/20030919 Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.5) Gecko/20030919 Incoming messages are being marked with UTC time despite existence of TZ system variable; sent messages use local time. Worked in 1.5b but not 1.5rc1. See attached "message source" and graphic capture of Mozilla mail window. On this system TZ=PST8PDT,4,1,0,7200,10,-1,0,7200,3600 Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: Mozilla should normalize Time/Date display to local time.
-> OS/2
Assignee: sspitzer → pedemont
OS: other → OS/2
This big also applies to Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.5) Gecko/20030930
This bug applies to Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.5) Gecko/20031017 as well. This can't be that difficult to fix! Alternatively, give me a location in OS2.INI to put the time zone info (since presumably Mozilla is trying to pull info from the Windows Registry) and I'll see if that takes care of the problem....
*** Bug 223512 has been marked as a duplicate of this bug. ***
*** Bug 223824 has been marked as a duplicate of this bug. ***
Confirmed in Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.5) Gecko/20031017
Status: UNCONFIRMED → NEW
Ever confirmed: true
Can you explain your TZ variable please?
Oh, I suppose that might cause trouble... :) TZ format is (condensed from documentation for Goran Ivankovic's World Clock v1.20): SET TZ=STD[+|-]nDST[,DSTm,DSTw,DSTd,DSTt,STDm,STDw,STDd,STDt,shift] where STD = Standard Time Zone Descripter (3 chars) n = Difference from STD to UTC in hours. DST = Daylight Savings / Summer Time descriptor (3 chars) XXXm = month STD/DST starts {1..12} XXXw = week STD/DST starts (1 = first, -1 = last) XXXd = day STD/DST starts (0 = Sunday, 6 = Saturday) XXXt = Time STD/DST starts in seconds from midnight shift = Size of time shift in seconds This format is also used in eComStation (per eCS Clock 1.00).
This problem was reported on the VACPP TZ bug (#137018) and have been addressed. It's fixed in the GCC 3.2.2 Beta3 fix1 which I put out a couple of days ago. The LIBC part of that fix can be downloaded at: http://download.innotek.de/gccos2/runtime/libc04fix1.zip
The replacement of libc04 doesn't resolve by itself the problem. Is it necessary to recompile Mozilla with corrected GCC?
After a system reboot (and the installation of libc04fix1), timestamps seems to be correct at last!
Fixed by using libc04fix1
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Verified per comment #11
Status: RESOLVED → VERIFIED
My emails are still 1 hour into the future. Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.6a) Gecko/20031103 My time zone is; TZ=AEST-10AEDT,10,-1,0,7200,3,-1,0,7200,3600 I changed it to TZ=EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 and it made no difference, reboots have no effect (I am using libc04fix) Current time is roughly 8:09 AEDT.
Has this bug been closed? I suspect that WORKSFORME nay have something to do with Daylight Savings time finishing in the northern hemisphere. Australia has just started Daylight Savings and the time shown on emails are 1 hour into the future! This could be verified if someone sets their TZ to a daylight savings zone and sends an email.
You may be right... The replace (+ Mozilla restart) of libc04 didn't resolve the bug by itself; I had to reboot OS/2 but, in the meantime, Daylight Savings time was ended.
This seems to be working for me with libc04fix1 and a system restart in 1.5 (and 1.6alpha) as with everyone else, but maybe it's something that needs to be verified in March/April as European Summer Time and US Daylight Savings Times take effect (I'll leave Australian times alone as they are too inconsistent for me to keep track of). I'll let the developers decide how to treat this. WORKSFORME works for me....
I'll reopen this bug based on feedback. I'll see if I can recreate with Australian TZ. If anyone else can check this out, also, I would grealy appreciate it.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
As a test I opened a command line window, typed "set tz=aedt-11" then ran mozilla. The time was then reported correctly on posts, so it definitely does not like the extra tz settings for daylight savings.
I don't know if it would work... it depends on whether or not the filename normalization routine translates periods to underscores. The UI directory stuff doesn't see "*.eml" as containing *.*.eml.
I'll add my two cents in here, based upon what I've been experiencing with 1.6a. Some info: User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.6a) Gecko/20031103 Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.6a) Gecko/20031103 It appears that libc04f1 (or something else) likes some TZ formats and doesn't like others. For example, the following otherwise valid TZ formats seem to be ignored: EST5EDT (pretty standard and old hat, but this one didn;t work for me) EST5EDT4,M4.1,M10.5 (not exactly compliant with the latest docs at http://www.gnu.org/software/libc/manual/html_mono/libc.html#TZ%20Variable) EST+5EDT,M4.1.0/M10.5.0 EST+5EDT,M4.1.0/2,M10.5.0/2 What does seem to work are the following: EST (that's a big help) EST5 (a little more help...) EST5EDT,4,1,0,7200,10,-1,0,7200,3600 (at least this one is fairly usable for other things, as well) Anyway, hopefully, someone here will be able to figure out what's being so fussy about the format. BTW, it appears as though ng posts seem to come through okay, even when POP messages are stripped of the TZ. I would surmise (though I haven't tested this) that IMAP may work, as well.
*** Bug 227622 has been marked as a duplicate of this bug. ***
*** Bug 227622 has been marked as a duplicate of this bug. ***
For those that are still seeing TZ problems, I need your help. Please post any TZ setting that works fine under Mozilla 1.4.x builds, but are 1 hour off on later builds (the difference in the builds is that 1.4.x builds are build with VACPP, while later builds are built with GCC). Thanks.
The Australian TZ settings appear OK in IWB 2.01 but not 1.6a TZ=AEST-10AEDT,10,-1,0,7200,3,-1,0,7200,3600
Per my own comment 21, the following worked fine under 1.4.1: EST5EDT EST5EDT4,M4.1,M10.5 EST5EDT,4,1,0,7200,10,-1,0,7200,3600 A dupe's a dupe's a dupe, I guess...
TZ on OS/2 is using the VAC syntax, not the standard described by anyone else.
Knut, are you referring to the TZ formats which are currently showing correctly, or the ones which are incorrect?
Neither. I were commenting on comment #21 and the introduction of the Unix TZ standard. On OS/2 there is a de facto TZ format used by VAC, Watcom and EMX at least. The OS/2 format is described in comment #8. It shares only the first format described in the link in #21. As to the problems, they should be fixed in the next release of libc.
Shouldn't we at least recognize the Unix formats (or is this what you mean when you say that these problems should be fixed in the next release of libc)? Other things do (on a per-application basis, obviously). I got by for ages using the format I had, until this thing with Mozilla (though, in all fairness, I just discovered on my Apache server running WSeB that PHP 4.3.4 ignored my TZ format until I changed it to the "OS/2 standard"). Lewis
You just pointed out the exact reason why it is such a bad idea to support the UNIX standard format. It will allow you to make Mozilla work, while breaking all other applications. So, in my opinion it's much better to force you to use the format which all applications on OS/2 understand. Kind Regards, knut PS. I can see that supporting the UNIX standard format might be a value add for porters of other applications, like for instance php and mysql. Testsuites of those applications often set TZ to different values to test the implementation of various time and date functions. But I trust that if any porter care for such a feature they will send me a patch for it.
Daylight savings are back in Europe at least, anyone still having trouble? I can't reproduce it anylonger at least. So, maybe we could close this bug? Kind Regards, knut
May be worth another week, as US daylight savings time starts this Sunday. Since the one person I'm having mail timestamp problems with at the moment is in Denver, I'll be satisfied if his mail continues to be an hour off.... :)
Here in Europe all continues to work fine.
Chatzilla time also broken.
felix: what is your TZ variable set to?
My TZ is set to MST7MDT,4,1,0,7200,10,-1,0,7200,3600 Since the DST change my clock shows the correct time and Lotus Notes shows the time correctly but Mozilla is an hour advanced. Also the correct time is shown in OpenOffice beta 3 and pronews. Andy
Full message (less .sig) from email today sent with OS/2 trunk: [begin] From - Mon Apr 05 10:55:02 2004 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 Message-ID: <40717344.4030201@ij.net> Date: Mon, 05 Apr 2004 10:55:00 -0400 From: Felix Miata <mrmazda@ij.net> User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7b) Gecko/20040404 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pedemont@us.ibm.com CC: mkaply@us.ibm.com, bird-mozilla@anduin.net Subject: Bug 137018 Test Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This is an email test. Time display is broken in Chatzilla, displaying time 1 hour into the future. Time now is 09:55:00 [end] [C:\] set | find "TZ" TZ=EST5EDT,4,1,0,7200,10,-1,0,7200,3600
The UCT offset (-0400) is correct, but the time isn't. Which means that the TZ value is understood by libc, but mozilla/libc is miscalculating the time change for some reason. I don't know the internals of mozilla in that respect and will require some guidance as to how mozilla makes this timestamp. A testcase program which does this timestamp calculation could be very helpful.
Well, I just tried it on my system with a trunk build. Set TZ to "cst6cdt,4,1,0,7200,10,-1,0,7200,3600". Posted a message and everything showed up just fine. Posted a newsgroup message, and it showed the right time. Still no idea why this doesn't work for some.
I think this problem is in PR_Now() and not the X-platform time explosion code. The problem is _probably_ related to value DosGetDateTime() returns in the timezone field. Normally that's -1 because noone normally sets it on OS/2. However, if it's not -1 on someones machine, ftime() (which is used to implement PR_Now() on OS/2) will do some adjustments to the value returned. ftime() assumes that the field is the current timezone offset in minutes. Felix Miata: do you have a OS/2 C compiler (any) and the OS/2 toolkit around? If so build and run this: #define INCL_BASE #include <os2.h> #include <stdio.h> int main() { DATETIME dt; DosGetDateTime(&dt); printf("timezone=%d\n", dt.timezone); return dt.timezone != -1; /* return 0 if -1, else fail with 1. */ } /* end */ (Hope this compiles, didn't test it.) If it's not -1 someone (not OS/2) is setting it. The questions are whether or not it is (and should) be dst adjusted, and who is setting it. Kind Regards, knut
btw. If my brain is still working (it's late here) I think the output you should see is: timezone=240 If it is that explains the problem. It will then be a bug in ftime() which isn't taking dst into account when adjusting using the timezone value as it perhaps should. Kind Regards, knut
If someone with those tools can make a little .com or .exe I would be only too happy to run it.
When I boot my Dec 2003 configuration (MCP FP2) the displayed time is correct, but on this system (eCS 1.1 FP4) the displayed time is 1 hour future. Time zone is set the same on both, EST5EDT.
I ran this on my machine and got timezone=360 and my TZ is MST7MDT,4,1,0,7200,10,-1,0,7200,3600 Andy
When I boot my Dec 2003 configuration (MCP FP2) with the displayed time correct, the result of running Andy's attachment is -1. On this system (eCS 1.1 FP4) that displays the time 1 hour future, the result of running Andy's attachment is 240.
Here is the original VACPP testcase I believe; #include <sys/timeb.h> main(int argc, char *argv[], char *envp[]) { struct timeb b; ftime(&b); printf("dstflag=%d\n", b.dstflag); } With the broken VACPP, dstflag was 0. with the fixed VACPP, dstflag was 2. This was with my TZ variable set to cst6cdt or est5edt.
I think we've found the problem then, ftime() isn't using the DATETIME::timezone value correctly. We're discussing how to make the fix available. Kind Regards, knut PS. if anyone could figure out which program/programs which is/are setting the timezone value (OS/2 is AFAIK NOT setting it) that would be appreciated. The suspects are OS/2 logon and any NTP (Network Time Protocol) clients.
> PS. if anyone could figure out which program/programs which is/are setting the > timezone value (OS/2 is AFAIK NOT setting it) that would be appreciated. The > suspects are OS/2 logon and any NTP (Network Time Protocol) clients. eCS ships with Mark Eckstein's eClock that sets the TZ string. from config.sys: REM SET *** The TZ string is maintained by eCS Clock. Do not change manually! Please refer to the clock's manual. *** SET TZ=MST7MDT,4,1,0,7200,10,-1,0,7200,3600 OS/2 defaulted to TZ=MST7MDT (format not this string per se) and was set by tcpip configurator. Andy
I was not talking about who contstructs the TZ environment variable, but who is setting the DATETIME::timezone. Meaning, which program causes the output of that test.exe to not be "timezone=-1". It's usually a program which adjusts/changes the time. And it's not lan server logon (just tested that). Kind Regards, knut
Eliminating RUN=F:\ECS\SYSTEM\ECLOCK\CLKBASIC.EXE from CONFIG.SYS fixes it for me.
hopefully innotek won't get made at me: http://download.innotek.de/gccos2/runtime/libc-0.5.1.exe fixes this It was a GCC bug.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → INVALID
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: