Re: [hatari-devel] GEMDOS bug: 5.10.2 Tgetdate off by one day, 5.10.3 Tgettime reports wrong time

["Roger Burrows" <anodyne@xxxxxxxxxxxx>]

On 25 Dec 2018 at 12:56, Charles Curley wrote:

> On Tue, 25 Dec 2018 10:19:53 +0100
> Christian Zietz <czietz@xxxxxxx> wrote:
> 
> > In Hatari, if you want to use your host's local time, you have to
> > emulate a machine *with* real time clock (e.g. MegaST). If, on the
> > contrary, you select an ST, at powerup EmuTOS will behave like on a
> > real ST, which doesn't have a RTC, either. I.e. EmuTOS will set the
> > IKBD date to its compile date (which probably was just one day off)
> > and the IKBD time to 00:00:00.
> 
> Curiouser and curiouser.
> 
> I switched emulation to an STE, and the time and date are reported
> correctly, so that will work for my purposes. Thank you.
> 
> The actual dated of compilation is Dec 18 14:26. And as an ST, the date
> emuTOS now reports is still the 23rd.
> 
The Mega ST(e) has an RTC, the ST(e) does not.  The initial wall-clock date 
used by EmuTOS on a machine without an RTC is the date from os_dosdate in the 
osheader (in this case, the initial wall-clock time is 00:00:00).  That date 
comes from bios/header.h, which is generated automatically by the awk script 
mkheader.awk, which is run by the Makefile.

If you are building EmuTOS yourself, and you make a change and rebuild without 
causing header.h to be recreated, then you will get the date that header.h was 
originally created.  This is arguably a bug in the Makefile.

I'm not sure how you would get a date *later* than the actual build date.

Roger