Comments you submit will be routed for moderation. If you have an account, please log in first.

Opened 6 years ago

Closed 3 years ago

Last modified 2 years ago

#10 closed bug (fixed)

DST changes *every* time in main window listview

Reported by: coldhoff Owned by: damato
Priority: high Milestone: YAM 2.9
Component: user interface Version: 2.5
Severity: major Keywords:
Cc: OS Platform:
Blocked By: Blocking:
Release Notes:

implemented a completely new procedure to deal with timezone and daylight saving times as the old method were unable to identify the daylight saving time for past dates. Now the official timezone databases published by are used instead. This finally corrects the time display for old mails when DST times changes relative to the current date/time.

Description (last modified by damato)

Today when most European countries switched to daylight saving time (DST), I noticed a bug in YAM25dev (am using the version from 27 March for m68k on AMIGA OS3.9BB2):

I have the main window listview configured to show the message date. After switching to DST, all times were increased by one hour, including the ones of mails received during standard time.

This is easy to reproduce:

Begin with DST, GMT+2 in my case, note the times displayed for some mails in a folder received during before (GMT+1) and after (GMT+2) the DST switch. Then uncheck the DST switch in the YAM config-"First steps". All times are changed.

Of course one can always open the mail to get the correct time including time zone info form the Date header field, and one may thus argue that this is a case for a feature request. However, I consider this a bug.

Moved from SF:

Attachments (3)

YAM-example (4.5 KB) - added by coldhoff 6 years ago.
Example mail
YAM-1.jpg.JPG (179.4 KB) - added by coldhoff 6 years ago.
YAM-1, main window list view
YAM-2.jpg.JPG (132.5 KB) - added by coldhoff 6 years ago.
YAM-2, Read window view of mail

Download all attachments as: .zip

Change History (21)

comment:1 Changed 6 years ago by damato

  • Priority changed from major to undecided
  • Severity set to major

comment:2 Changed 6 years ago by damato

  • Component changed from nightly build to undefined

comment:3 Changed 6 years ago by damato

  • Cc yamos-svn@… removed

comment:4 Changed 6 years ago by damato

  • Component changed from undefined to user interface
  • Priority changed from undecided to low
  • Severity changed from major to minor
  • Status changed from new to pending

Is this bug still valid with YAM 2.6? Please report back so that we can investigate and fix it for 2.7.

comment:5 Changed 6 years ago by coldhoff


The bug is still there in YAM 2.6.
Viewing a mail received last summer, the time displayed (now, in March) is what it would be if there were no DST here in Europe. In April, the correct time will be
displayed again.

C Oldhoff

comment:6 Changed 6 years ago by damato

  • Reporter changed from coldhoff@… to coldhoff

Can you provide an example email please with a detailed explaination and perhaps screenshots which time is shown and which time you expect to be shown for a certain email. thanks.

Changed 6 years ago by coldhoff

Example mail

comment:7 Changed 6 years ago by coldhoff

  • Status changed from pending to new

Attachment (YAM-example) added by ticket reporter.

Changed 6 years ago by coldhoff

YAM-1, main window list view

Changed 6 years ago by coldhoff

YAM-2, Read window view of mail

comment:8 Changed 6 years ago by coldhoff

The mail is displayed at the last line in the main window list view of messages.

It was sent during last summer at 9:58 CET and I also reside in this time zone.

The main window displays this as 8:58, which would be correct time if their were
no DST in Europe. Only when DST is in effect here the time is correctly displayed
as 8:58.

Since I sometimes need to know exactly when I received a message from someone, I
have to think twice to get it right when DST has changed.

It would be nice if the main window list view of the messages actually displayed
what the time was in my time zone when the message was sent.

comment:9 Changed 3 years ago by damato

  • Description modified (diff)
  • Milestone set to YAM 2.8p1
  • Priority changed from low to high
  • Severity changed from minor to major
  • Status changed from new to accepted

After investigation this ticket I think you are perfectly right in complaining that YAM doesn't display the actual time corrected to your timezone that was effective at the time the mail has been sent. As it stands let me summarize the problem as followed:

  1. You receive a mail written in summer time (DST) at e.g. 09:00:00 CEST (+0200).
  2. When you receive and view it at the same day also 09:00:00 is displayed which is perfectly correct.
  3. Lets assume now some time passed and it is winter time now which is actually CET (+0100).
  4. If you view the mail again YAM will identify that the mail in question was written in CEST (+0200) while the current timezone ist CET (+0100). Thus it will substract one hour and display it as 08:00:00 in the main mail listview.
  5. However, thinking about that matter this is incorrect as a user is interested to know what the time actually was in the past relative to his current timezone.

But to actually fix the problem there arises the problem that yam have to be able to actually know which timezone (CEST vs CET) was affective at a certain date in the past. Thus, we have to have a function to which you supply a date and it will output that at that date it was either +0100 (CET) or +0200 (CEST). Another problem is that daylight saving times tend to change in the future (politically driven) which requires not have something hardcoded by to use a kind of functionality to even correctly query in the future at which date daylight saving was in effect or not (just in case a country changes their rules).

Nevertheless, I count this issue a highly important thing as the current situation is really incorrect and just confuses users as it is correctly outlined by the authors of this ticket. Thus, I will assign it to the next release and give it some priority instead of just for a future release. So lets discuss how we can correctly fix the issue.

comment:10 Changed 3 years ago by damato

After some more investigation and search on the net I found the following potential solution to find out if a certain date was in DST or non-DST:

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


enum DST getdstinfo(int year, int month, int day) {
    struct tm a = {};
    struct tm b;
    a.tm_isdst = -1;
    a.tm_mday = day;
    a.tm_mon  = month - 1;
    a.tm_year = year - 1900;
    b = a;
    a.tm_hour = 23;
    a.tm_min = 59;

    if      (a.tm_isdst  && b.tm_isdst)  return DST_ON;
    else if (!a.tm_isdst && !b.tm_isdst) return DST_OFF;
    else if (a.tm_isdst  && !b.tm_isdst) return DST_OFFTOON;
    else                                 return DST_ONTOOFF;

void main(void)
  printf("DST1: %d\n", getdstinfo(2012, 3, 24)); // should return 0
  printf("DST2: %d\n", getdstinfo(2012, 3, 25)); // should return 2
  printf("DST3: %d\n", getdstinfo(2012, 3, 26)); // should return 1
  printf("DST4: %d\n", getdstinfo(2012, 5, 22)); // should return 1

However, unfortunatly at least unter OS4 it always returns "1", on MorphOS it always returns "0" while on linux it correctly returns the sequence 0,2,1,1. So I guess OS4 and MOS and also probably OS3 don't have the proper functionality to identify if a certain time_t is/was in dst or not.

So we still have to search for a potential solution to identify if a certain date was in dst or not. Thore? do you know any solution?

comment:11 Changed 3 years ago by damato

(In [6619]) * extrasrc/tzcode: added sources of zoneinfo sources for common functions

like localtime(), mktime(), etc. These sources are under public domain and
were taken from tzcode2013a.tar.gz (
This refs #10.

comment:12 Changed 3 years ago by damato

(In [6620]) * extrasrc/tzcode, lib/*/libtz.a: added Makefile to the new zoneinfo functions

and adapted them to be compiled for all Amiga platforms. However, they still
need to be adapted to work as expected. Added first versions of libtz.a for
all supported platforms in the lib path. This refs #10.

comment:13 Changed 3 years ago by damato

(In [6621]) * resources/zoneinfo, tools/tzdata: added raw source files of the tzdata2013a

zoneinfo archive taken from and added a new shell
script to generate zoneinfo binary files in the newly created "zoneinfo"
directory in the resources path of YAM. This will allow to use these files
with our new zoneinfo query functions in libtz.a. This refs #10.

comment:14 Changed 3 years ago by damato

  • Milestone changed from YAM 2.8p1 to YAM 2.9

As it stands we are not able to finally fix that issue for 2.8p1. In addition, as it requires quite a large amount of changes to yam we will reschedule it for 2.9 instead. However, the issue is understood and a solution exists, but it needs to be implemented and tested throughoutly.

comment:15 Changed 3 years ago by damato

  • Owner changed from somebody to damato
  • Status changed from accepted to assigned

comment:16 Changed 3 years ago by damato

(In [6797]) * TZone.c, misc: first large overhaul of the management of timezones and

where YAM is getting the GMT offset and daylight saving time (DST)
information from. Previously, YAM was trying to get both from the system
itself which only worked reliably for AmigaOS4. In addition, it was
trying to use all kind of third-party tools like SetDST, FACTS, etc.
for other systems which also made things way to complicated. Now with
this change YAM is finally using an own timezone database and
functionality based on the official tzdata/tzcode library from
This should make timezone and DST guessing much more reliable and
less cumbersome. In addition, this new functionality will finally fix
certain flaws. Thus, this refs #10.

comment:17 Changed 3 years ago by damato

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [6823]) * YAM_UT.c: now that we have finally the infrafracture to identify which gmt

offset was effecitive at a certain date+time (even DST) the TZConvert()
functions have been changed now to actually take care of that and not
simply convert DateStamp/TimeVal values according to the currently
effective gmt offset. This finally fixes a long standing flaw in the
display of time values in the main mail list and closes #10.

comment:18 Changed 2 years ago by damato

  • Release Notes modified (diff)

Add Comment

Modify Ticket

as closed The owner will remain damato.
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber

  • Christer Oldhoff(Reporter, Participant)
  • Jens Maus(Owner, Participant)