Closed Bug 137018 Opened 22 years ago Closed 20 years ago

[4xp] Incorrect Time Display For Posts While Daylight Savings Time

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
OS/2
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mrmazda, Assigned: mkaply)

References

Details

Attachments

(1 file)

2002041109 OS/2

Steps to reproduce:
1-View posts in Mozilla
2-View sames posts in Netscape 3 or 4

Actual behavior:
1-Time is correctly displayed in Netscape 3 or 4
2-Time is one hour earlier than it should in Mozilla

Expected behavior:
1-Time shows the same regardless of app used to display

Compare to bug 118899. Could fix be related?
CONFIG.SYS contained 'SET TZ=EST5EDT' for the original creation of the
screenshot displayed posts.
Keywords: 4xp
I also filed bug 137037, which I'm sure is related. But, I don't think they
represent the exact same problem. When email or news is sent using Mozilla,
viewing the sent folder or the post in the newsgroup, Mozilla shows the correct
time for the posts you sent with it, but only because it is making the same
error again, which cancels the apparent effect. Because of bug 118899 effect,
you can't tell about time display or actual zone corrector errors of other posts
without using some other email/news reader.
*** Bug 137037 has been marked as a duplicate of this bug. ***
This is definitely a bug in VACPP handling of DST.

We have opened a bug against the compiler folks.

There is no easy workaround at this time.
Assignee: sspitzer → mkaply
Status: UNCONFIRMED → NEW
Ever confirmed: true
We found a workaround but I would like to emphasize that I am not accepting this 
as the fix. We are still pushing the compiler team.

See:

http://www2.hursley.ibm.com/goserve/$GoSer50.htm

If you specify explicitly the starting days/times for DST, it supposedly should 
work. I haven't tested this.
We got the fixes DLL from the compiler team and have integrated it into all 
our builds.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Verified fixed in trunk 2002053008.
Status: RESOLVED → VERIFIED
Same problem now with emx builds: my TZ is
ECT-1CEST,3,-1,0,7200,10,4,0,10800,3600 but mails are sent with +0000
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
>Same problem now with emx builds: my TZ is
>ECT-1CEST,3,-1,0,7200,10,4,0,10800,3600 but mails are sent with +0000
4 character timezones were broken in EMX, LIBC01 and LIBC02. 
It should be fixed in LIBC03 which we released last week. You should re-check
test problem with a build which is using LIBC03 - such a build is not yet
available and I don't know when Mike and his team will do one, but I'm kind of
hoping 1.5rc1 will be done using that LIBC and GCC release.
Seems to be fixed in 1.5rc1.
WFM
Status: REOPENED → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
My TZ is: CET-1CDT,3,-1,0,10800,10,-1,0,7200,3600 (created with TZ Calculator).
Everything worked fine for me until 1.5b; now, with 1.5rc1, every mail sent by
me has the "Date:" field one hour forward (using every possible mail reader,
1.5rc1 included).
LIBC03/mozilla should work fine with this TZ. Previous releases of LIBC (ie.
LIBC02, LIBC01 & LIBC00) probably didn't.

BTW. The right one for Italy is supposed to be (according to some other Italian
guy):
  CET-1CDT,3,-1,0,7200,10,-1,0,10800,3600
You mixed the start and end time of the daylight saving.

For the other with TZ issues: There are some a bug left in the code which
prevents TZ values like PST8PDT. We're fixing it.
LIBC04 and Mozilla 1.5 "GA"... the problem still persists...
We've fixed the problem in GCC 3.2.2 Beta 3 which was released a couple of days ago.
The updated LIBC can be downloaded at:
http://download.innotek.de/gccos2/runtime/libc04fix1.zip
Since this vacpp bug was marked fixed over a year ago, isn't the right place for
discussing recent gcc problems bug 220850?
Status: RESOLVED → VERIFIED
Not fixed. Time local is 09:56 -0400.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Why did you reopen this?

GCC problems are to be discussed in bug 220850

This bug was about VACPP.
Status: REOPENED → RESOLVED
Closed: 21 years ago20 years ago
Resolution: --- → FIXED
I found this first, with a patch, and comment 15 discussing the supposed gcc
fix. So, I didn't look for another.
Status: RESOLVED → VERIFIED
For posterity, I'm posting the testcases we sent to VACPP:

Test case #1

#include <time.h>
#include <stdio.h>
#include <stdlib.h>

main(int argc, char *argv[], char *envp[])
{
   time_t Secs;
   time_t Secs2;
   struct tm *LocalTime;
   struct tm *SecondsTime;

   /*_putenv("TZ=CST6CDT,4,1,0,3600,10,-1,0,7200,3600"); /*Central*/
   /*_putenv("TZ=EST5EDT,4,1,0,3600,10,-1,0,7200,3600");*/ /*Eastern*/
   /*_putenv("TZ=PST8PDT,4,1,0,3600,10,-1,0,7200,3600");*/ /*Pacific*/
   _tzset();     

   time(&Secs);
   LocalTime = localtime(&Secs);

   if (LocalTime->tm_isdst) {
      printf("DST is on\n");
   } else {
      printf("DST is off\n");
   }

   Secs2 = 1018894369;
   SecondsTime = localtime(&Secs2);
   printf("Hour = %d\n", LocalTime->tm_hour);
   printf("Hour should be 13 if we are in DST"); /*13 for CDT only*/

   return 0;
}

Test case #2

 #include <time.h>
 #include <stdio.h>
 #include <stdlib.h>
 
 int main(){
     time_t t;
     struct tm *pTime;
 
     /*_putenv("TZ=EST5EDT,4,1,03600,10,-1,0,7200,3600");*/
     _tzset();
 
     time(&t);
     pTime = localtime(&t);
 
     printf("pTime->tm_isdst (DST indicator) = %d ==> ");
     printf("%s\n", (pTime->tm_isdst > 0) ? "on" : "off");
     printf("_daylight  = %d\n",_daylight);
     printf("_timezone  = %ld\n",_timezone);
     printf("_tzname[0] = %s\n",_tzname[0]);
     printf("_tzname[0] = %s\n",_tzname[1]);
 
     return 0;
 }
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: