Re: [hatari-devel] GEMDOS HD vs. host timestamps (was: New Hatari release?)

[Thorsten Otto <admin@xxxxxxxxxxx>]

On Dienstag, 6. Februar 2018 19:14:15 CET Eero Tamminen wrote:

I'm not Uwe, but i think i have to comment on it anyway ;)

> However, it seems that TOS reads RTC only at boot, so after
> that it will drift away from host clock.

That's not entirely true. It is read at boot, and on every Gettime() BIOS 
call. It is not read however on Tgetdate()/Tgettime(). The Gettime() call will 
update some private variables, which are incremented in the hz200 interrupt, 
and returned by Tgetdate()/Tgettime().

> Case B:
> - 1) & 2) are both on host side
> 
> -> everything works fine by default

And that is the case that is not working currently. Hatari reads the date/time 
only once, then does its own increment. That will be updated much slower than 
realtime, when using fast-forward. What happens is that the file is created on 
the host filesystem (with the real date of the host). There is no explicit 
Fdatime() call after that to set it to the current (GEMDOS) time, since it is 
expected that this is already the case. The GEMDOS time however will be much 
behind, and that is what every project management, be it PureC or make, will 
confuse.

Using --gemdos-time atari might fix that, but then you have files on the host 
which you just created, but have dates in the past. That is actually nonsense.

No matter which setting you use, there will always be a discrepance between 
current date, and timestamps of files just created.