DST changes *every* time in main window listview

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

Hello,

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.

Regards,
C Oldhoff

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.

Example mail

Attachment (YAM-example) added by ticket reporter.

YAM-1, main window list view

YAM-2, Read window view of mail

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.

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.

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 { DST_OFF, DST_ON, DST_OFFTOON, DST_ONTOOFF };

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;
    mktime(&a);
    mktime(&b);

    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?

(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 (​http://www.iana.org/time-zones).
This refs #10.

(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.

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

zoneinfo archive taken from iana.org and added a new mktzdata.sh 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.