[Oberon] File time stamps in PO2013

Charles Perkins chuck at kuracali.com
Fri Feb 14 01:39:01 CET 2020


Thanks Joerg and Michael,

I thought maybe I was missing something. I guess you can only do so much
with 32 bits!

Chuck

On Thu, Feb 13, 2020 at 12:59 PM Michael Schierl <schierlm at gmx.de> wrote:

> Hello,
>
>
> Am 13.02.2020 um 20:36 schrieb Charles Perkins:
>
> > 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.
>
> If you want it updated from the millisecond timer (on demand when
> Kernel.Clock is read), you can use this patch:
>
> <
> https://github.com/schierlm/Oberon2013Modifications/blob/master/RealTimeClock/RealTimeClock.patch
> >
>
> If you are using any of my emulators, you can add this patch to get it
> initialized at boot time:
>
> <
> https://github.com/schierlm/Oberon2013Modifications/blob/master/RealTimeClock/EmulatorSupport.patch
> >
>
> Currenty it will initialize the year with 20 that way. You could also
> initialize it with 0, and gain 20 more years. I would not initialize it
> with 10 (when you use my code) since it will break the leap year
> detection (in case you ever keep the system running past midnight on the
> last day of February).
>
> > 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?
>
> I would say that is a bad choice (if you do not change the output code
> for System.Directory), since that output code will output the year
> number in a form that makes you assume it is a 2-digit year.
>
> > Am I over-thinking this?
>
> Probably, too :)
>
>
> Regards,
>
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200213/cde27c20/attachment.html>


More information about the Oberon mailing list