Hi there,
On Sat, 16 Nov 2024, Jon Brase via Freedos-user wrote:
The list is full of corner cases ...
Reproduced below is an extract from a 'C' header file, which is still
current here and is used to build systems under both DOS and Linux to
handle a lot of money for both my business and thos
The list is full of corner cases that programs actually have to deal with
in real life, no matter how insane they seem, that break schemes like
"maintain separate day and second counts".
On Fri, Nov 15, 2024, 17:10 tsiegel--- via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:
> Yeah, t
What I don't understand is why there's an insistence on keeping the rate of
UTC identical to TAI and inserting leap seconds. Why not just define the
UTC second to be the advancement of Earth's 0-longitude line by 15
arcseconds relative to the sun (in other words, make the Earth's rotation
the refer
Yeah, thanks, complete waste of time. If any decent programmer believes
even a quarter of that list, they aren't very good programmers.
(admittedly, there are 2 or 3 items on that list that don't appear to be
falsehoods, but I leave that up to the experts, since 99 percent of the
list was per
Not that it matters, but I understand all of those things (and more)
just fine.
What the computer does to represent time has absolutely no bearing on
any of those external processes in any way shape or form.
For all it matters, the computer could use a huge number of locations in
memory, and
>
> What I don't understand is why there's an insistence on keeping the
> rate of UTC identical to TAI and inserting leap seconds. Why not just
> define the UTC second to be the advancement of Earth's 0-longitude
> line by 15 arcseconds relative to the sun (in other words, make the
> Earth's rotat
On Fri, Nov 15, 2024, 11:50 Jim Hall via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:
> On Fri, Nov 15, 2024 at 11:45 AM Jon Brase via Freedos-user
> wrote:
> [..]
> >
> > If Earth's accumulated rotation angle is ever non-monotonic, we'll
> > have bigger and more thermally significan
On Fri, Nov 15, 2024 at 11:45 AM Jon Brase via Freedos-user
wrote:
[..]
>
> If Earth's accumulated rotation angle is ever non-monotonic, we'll
> have bigger and more thermally significant problems than timekeeping.
You might be surprised to learn the Earth's rotational speed actually
*does* chang
> On Tue, 12 Nov 2024 at 15:53, tsiegel--- via Freedos-user
> >
> > To solve the whole time/date problem, I never understood why they
> > don't separate the two. Time could then be a regular integer, since
> > there's only 86,400 seconds in a day.
>
Hmm. I have to give this idea some credit, in t
On Tue, 12 Nov 2024 at 15:53, tsiegel--- via Freedos-user
wrote:
>
> To solve the whole time/date problem, I never understood why they don't
> separate the two. Time could then be a regular integer, since there's
> only 86,400 seconds in a day.
I am almost speechless. That is beyond inane.
Hint
Hallo Herr tsiegel--- via Freedos-user,
am Dienstag, 12. November 2024 um 16:39 schrieben Sie:
> To solve the whole time/date problem, I never understood why they don't
> separate the two. Time could then be a regular integer, since there's only
> 86,400 seconds in a day. Then simply make the
The real way to deal with time/date bugs forever is a 512-bit timestamp,
with a 144-bit subsecond part and a 368-bit second count. This provides
resolution on the order of 1 Planck time for over 10^100 years, which
should be sufficient for as long as computers will be needed, and to cover
all fores
To solve the whole time/date problem, I never understood why they don't
separate the two. Time could then be a regular integer, since there's
only 86,400 seconds in a day. Then simply make the date the number of
days (instead of number of seconds) from some arbitrary start date.
This would s
Hi there,
On Tue, 12 Nov 2024, Frantisek Rysanek via Freedos-user wrote:
...
You are possibly safe on a modern 32bit platform as well, because the
C type may be #defined with explicit length ...
Some libraries switched from signed to unsigned 32-bit integers for time_t
which kicks the can dow
> String "DOS" is absent from
> https://en.wikipedia.org/wiki/Year_2038_problem. Has anything been
> done or planned to deal with it in FreeDOS, or the legacy filesystems
> it supports?
The UNIX epoch time is originally a 32bit integer in seconds, since
1.1.1970. Not defined to be signed, but of
DOS APIs have support up until 2099.
https://fd.lod.bz/rbil/interrup/dos_kernel/215700.html
https://fd.lod.bz/rbil/interrup/dos_kernel/2f120d.html
https://fd.lod.bz/rbil/interrup/dos_kernel/215700.html
https://fd.lod.bz/rbil/interrup/dos_kernel/215706.html
On Mon, Nov 11, 2024 at 4:58 PM Felix M
String "DOS" is absent from https://en.wikipedia.org/wiki/Year_2038_problem. Has
anything been done or planned to deal with it in FreeDOS, or the legacy
filesystems
it supports? Google turned up nothing useful about DOS. In Linux
"ext2 filesystem being mounted at /disks/boot supports timestamps u
17 matches
Mail list logo
