|Re: [hatari-devel] GEMDOS bug: 5.10.2 Tgetdate off by one day, 5.10.3 Tgettime reports wrong time|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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.