[Oberon] File time stamps in PO2013

[Jörg]

Hi again

 

For a) I would use the following formula:

   dt := ((((yr*12 + mo)*24 + hr)*32 + day)*64 + min)*64 + sec;

        (* the higher 15 bits encode yr, mo and hr

             the lower 17 bits encode day, min and sec *)

 

For b) I would use the following formula

   dt := ((((yr*16 + mo)*32 + day)*32 + hr)*64 + min)*32 + sec DIV 2;

 

br

Jörg

 

Von: Joerg <joerg.straube at iaeth.ch>
Datum: Donnerstag, 13. Februar 2020 um 21:00
An: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Betreff: Re: [Oberon] File time stamps in PO2013

 

Firstly, I wrote a RealTimeClock background task for ProjectOberon that increments Kernel.clock based on Kernel.timer. My SW accuracy is almost as high as a HW RTC.

 

Secondly, here are two approaches to fix this 63 years restriction of the current implementation

a) 100 years are less than 2^32 seconds, so we can fit them in 32 bits but we cant use powers of 2 anymore to split the fields.

b) use a granularity of 2 seconds for clock iso 1 second. Then you get 1 bit more for the year and you can code the year from 00..99

 

I did not make up my mind whether a) or b) is better, or we should just live with the restriction and set the base year to eg 2010. Then the problem only appears in 2073.

 

Jörg




Am 13.02.2020 um 20:36 schrieb Charles Perkins <chuck at kuracali.com>:



I'm writing a linux kernel filesystem driver for Project Oberon disk images and I'm wondering how best to interpret the Date field in the FileDesc record. 

 

It looks to me like the Files module just puts the latest Kernel.Clock() value in there when the file is written.

 

System.Mod sets the date value like this:

dt := ((((yr*16 + mo)*32 + day)*32 + hr)*64 + min)*64 + sec;

 

It looks to me like the above formula leaves 6 bits for the year, which means it ranges from 0 to 63.

 

Now I know that the FPGA doesn't actually have a real time clock and I think the time is always actually zero unless you set it to something else. I don't think it gets updated from the system millisecond timer either.

 

I'm just wondering if historically that year value that goes in a file header has a base year  or other meaning. Without something like that the maximum year is "63" which is a long time ago!

 

I'd like to put something meaningful in this field when I move files in and out of Linux.

 

Anybody have a good idea? Should I just make it based on Jan 1 1970 like Unix, in which case it rolls over in 2033?

 

Am I over-thinking this? 

 

Chuck

 

 

 

--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200213/3fb19a8e/attachment.html>