How do I know,

My kitchen lamp died on 2-1-2022 lol.

It's a message from some external universe.

Let's see if it becomes true ! =D

Bye,
Skybuck.

On Sunday, January 2, 2022 at 11:02:40 PM UTC-6, skybuck2000 wrote:
> How do I know,
>
> My kitchen lamp died on 2-1-2022 lol.
<
Your kitchen lamp died on Feb 1, 2022 ?!? How prescient of you.
>
> It's a message from some external universe.
>
> Let's see if it becomes true ! =D
>
> Bye,
> Skybuck.

MitchAlsup [2022-01-03 09:21:53] wrote:
> On Sunday, January 2, 2022 at 11:02:40 PM UTC-6, skybuck2000 wrote:
>> How do I know,
>> My kitchen lamp died on 2-1-2022 lol.
> Your kitchen lamp died on Feb 1, 2022 ?!? How prescient of you.

I think he used the saner little endian notation.
Noone can always be wrong.

Stefan

On 03/01/2022 18:21, MitchAlsup wrote:
> On Sunday, January 2, 2022 at 11:02:40 PM UTC-6, skybuck2000 wrote:
>> How do I know,
>>
>> My kitchen lamp died on 2-1-2022 lol.
> <
> Your kitchen lamp died on Feb 1, 2022 ?!? How prescient of you.

Dates in most of the world are ordered more logically than the USA -
either day, month year, or year, month, day.

Mind you, the PDP-endian US format gave us the international holidays of
Pi Day and Star Wars Day, so it has /some/ uses!

:-)

Le 03/01/2022 à 19:16, David Brown a écrit :
> On 03/01/2022 18:21, MitchAlsup wrote:
>> On Sunday, January 2, 2022 at 11:02:40 PM UTC-6, skybuck2000 wrote:
>>> How do I know,
>>>
>>> My kitchen lamp died on 2-1-2022 lol.
>> <
>> Your kitchen lamp died on Feb 1, 2022 ?!? How prescient of you.
>
> Dates in most of the world are ordered more logically than the USA -
> either day, month year, or year, month, day.
>
> Mind you, the PDP-endian US format gave us the international holidays of
> Pi Day and Star Wars Day, so it has /some/ uses!

Well, yes, I've always found US dates odd. I'm not a native speaker, so
I don't really know all the history. But in English, dates can be
written either "January 2" or "the 2nd of January". The number-only form
matches the first. I suppose this is because it's the more compact way
of expressing it, and americans tend to prefer compact and efficient.

On 03/01/2022 19:33, Guillaume wrote:
> Le 03/01/2022 à 19:16, David Brown a écrit :
>> On 03/01/2022 18:21, MitchAlsup wrote:
>>> On Sunday, January 2, 2022 at 11:02:40 PM UTC-6, skybuck2000 wrote:
>>>> How do I know,
>>>>
>>>> My kitchen lamp died on 2-1-2022 lol.
>>> <
>>> Your kitchen lamp died on Feb 1, 2022 ?!? How prescient of you.
>>
>> Dates in most of the world are ordered more logically than the USA -
>> either day, month year, or year, month, day.
>>
>> Mind you, the PDP-endian US format gave us the international holidays of
>> Pi Day and Star Wars Day, so it has /some/ uses!
>
> Well, yes, I've always found US dates odd. I'm not a native speaker, so
> I don't really know all the history. But in English, dates can be
> written either "January 2" or "the 2nd of January". The number-only form
> matches the first. I suppose this is because it's the more compact way
> of expressing it, and americans tend to prefer compact and efficient.

In Britain, "January the second" used to be a common verbal form for
dates, and is still used occasionally, especially amongst older people.
"2nd January" (written long form), or "The second of January" (spoken)
are much more common. When writing with a year, day-month-year order is
almost invariably used (except for some contexts in which ISO formats
such as 2022-01-02 are appropriate or more convenient).

Americans are more conservative, and resist change. The UK moved on to
the more logical and consistent format in the mid 20th century, but the
USA stayed behind (just like for measurement systems and 24 hour clocks.
Americans like to point out Fahrenheit, pounds and inches got them to
the moon - fair enough, but perhaps with a sane measurement system
they'd be on Mars by now).

There is nothing "compact" about the American way - it's just jumbled
and has no advantage compared to an consistent order. (Just as it's
okay to like little-endian, and to like big-endian, but PDP mixed-endian
is just awkward.)

On Monday, January 3, 2022 at 12:33:26 PM UTC-6, Guillaume wrote:
> Le 03/01/2022 à 19:16, David Brown a écrit :
> > On 03/01/2022 18:21, MitchAlsup wrote:
> >> On Sunday, January 2, 2022 at 11:02:40 PM UTC-6, skybuck2000 wrote:
> >>> How do I know,
> >>>
> >>> My kitchen lamp died on 2-1-2022 lol.
> >> <
> >> Your kitchen lamp died on Feb 1, 2022 ?!? How prescient of you.
> >
> > Dates in most of the world are ordered more logically than the USA -
> > either day, month year, or year, month, day.
> >
> > Mind you, the PDP-endian US format gave us the international holidays of
> > Pi Day and Star Wars Day, so it has /some/ uses!
> Well, yes, I've always found US dates odd. I'm not a native speaker, so
> I don't really know all the history. But in English, dates can be
> written either "January 2" or "the 2nd of January". The number-only form
> matches the first. I suppose this is because it's the more compact way
> of expressing it, and americans tend to prefer compact and efficient.

I suffix many of my file names by _yymmdd so files with otherwise identical names sort by date.
Also used on handwritten note pages
PDF files suffixed by author and year _nnn...yyyy
Is there a windows utility that will sort directories using the last letters and digits in the file name?

American, and have become more and more enamored of organizing stuff by date

Le 04/01/2022 à 01:14, JimBrakefield a écrit :
> I suffix many of my file names by _yymmdd so files with otherwise identical names sort by date.
> Also used on handwritten note pages
> PDF files suffixed by author and year _nnn...yyyy
> Is there a windows utility that will sort directories using the last letters and digits in the file name?

There may be. I don't know of one. Maybe have a look at Total Commander?

Otherwise, one thing you could do is to se the modification date of each
file to the date that is associated with it in the filename, using Power
Shell (see the part "To set the specific timestamps..."
https://www.shellhacks.com/windows-touch-command-equivalent/

And, I'm sure a small script could automate this. Not very proficient
with Powershell, but it should be straightforward.

After that, you can just sort the files by date in the file manager.

On 1/3/2022 6:14 PM, JimBrakefield wrote:
> On Monday, January 3, 2022 at 12:33:26 PM UTC-6, Guillaume wrote:
>> Le 03/01/2022 à 19:16, David Brown a écrit :
>>> On 03/01/2022 18:21, MitchAlsup wrote:
>>>> On Sunday, January 2, 2022 at 11:02:40 PM UTC-6, skybuck2000 wrote:
>>>>> How do I know,
>>>>>
>>>>> My kitchen lamp died on 2-1-2022 lol.
>>>> <
>>>> Your kitchen lamp died on Feb 1, 2022 ?!? How prescient of you.
>>>
>>> Dates in most of the world are ordered more logically than the USA -
>>> either day, month year, or year, month, day.
>>>
>>> Mind you, the PDP-endian US format gave us the international holidays of
>>> Pi Day and Star Wars Day, so it has /some/ uses!
>> Well, yes, I've always found US dates odd. I'm not a native speaker, so
>> I don't really know all the history. But in English, dates can be
>> written either "January 2" or "the 2nd of January". The number-only form
>> matches the first. I suppose this is because it's the more compact way
>> of expressing it, and americans tend to prefer compact and efficient.
>
> I suffix many of my file names by _yymmdd so files with otherwise identical names sort by date.
> Also used on handwritten note pages
> PDF files suffixed by author and year _nnn...yyyy
> Is there a windows utility that will sort directories using the last letters and digits in the file name?
>
> American, and have become more and more enamored of organizing stuff by date

I have typically used "YYYY-MM-DD", as it seemed obvious enough.
Annoyingly, I have found, other people IRL are hopelessly confused by
any date not in the 'MM/DD/YY' or 'MM/DD/YYYY' formats.

A lot of my documentation files have the origin date as a name prefix,
may eventually get updated, but usually reflects when the file was first
created more than when it was last edited (though, usually the
filesystem keeps note of this one).

But, oh well. Due to "ongoing can't seem to get anyone to consider
hiring me to do anything" issues (*), have started working on another 3D
engine. I suspect there is at least slightly higher probability of being
able to make something "marketable" as an indie game than with the BJX2
core. I found this project interesting, but there doesn't seem to be any
real potential way to get any sort of income from this (well, short of
GitHub Sponsors or similar, but this seems unlikely).

*: Like one can apply to lots of jobs, but invariably either hear
nothing, or get the occasional automated "screw off" email as a response
(whole life thus far is basically this).

I could have resumed working on my old 3D engine, but there was enough
stuff I wanted to do differently that it seemed better to pull a reset
(it was being based off of BtMini). Funny enough is that right now I
have an engine doing Minecraft style terrain but currently using around
40-60MB of RAM...

Though, the bigger RAM waster would likely be if I switched back to
per-chunk vertex arrays. At the moment, the renderer is based around the
use of ray-casts (cast a ray, and if it hits a block we haven't hit yet,
add it to the list; then draw all the blocks that were hit).

Drawback is that ray casting doesn't work as well with larger draw
distances. PC can afford a higher ray density and larger trace-distance
limit, but this only goes so far.

Some point may also need to switch it over to using the GPU for
rendering, at the moment I am using my software GL rasterizer, ...

Current idea otherwise is (besides the blocky terrain), trying to rip
ideas off of a few other (fairly popular) games (namely Undertale and
Stardew Valley). Well, and ye olde "retro aesthetic" (make the textures
32x32, use 32x64 pixel character sprites, use 8kHz ADPCM for sound
effects, ...).

As with my last effort, I am (again) going with sprite-based graphics
and atlas textures. Difference is mostly that I have (somewhat) reduced
the resolution. It is likely that "wander around and interact with NPCs"
will remain a focus.

Lacking much better, also just sort of going with an XML based notation
for the dialog and menu systems (and a "binary serialized XML" format
for the entity graph; ...). The last engine had tried to use a dialog
system built around building object graphs in code, but this was kinda
painful and didn't scale very well (and my ideas for a wiki-notation
format fizzled; but XML notation is at least competent at blobs of text
interspersed together with block structuring).

Though, even if it somehow "doesn't suck", the likelihood of "success"
is pretty low (given the huge number of indie games around, most of
which don't amount to much; and "no one cares", which is why I am here
to begin with).

Similar with writing Sci-Fi, never sold enough E-Books to actually make
anything from it (so, sadly, one needs some level of popularity as a
starting point).

Or, basically, all the reasons I am here to begin with.

....

On 1/3/2022 4:14 PM, JimBrakefield wrote:
> On Monday, January 3, 2022 at 12:33:26 PM UTC-6, Guillaume wrote:
>> Le 03/01/2022 à 19:16, David Brown a écrit :
>>> On 03/01/2022 18:21, MitchAlsup wrote:
>>>> On Sunday, January 2, 2022 at 11:02:40 PM UTC-6, skybuck2000 wrote:
>>>>> How do I know,
>>>>>
>>>>> My kitchen lamp died on 2-1-2022 lol.
>>>> <
>>>> Your kitchen lamp died on Feb 1, 2022 ?!? How prescient of you.
>>>
>>> Dates in most of the world are ordered more logically than the USA -
>>> either day, month year, or year, month, day.
>>>
>>> Mind you, the PDP-endian US format gave us the international holidays of
>>> Pi Day and Star Wars Day, so it has /some/ uses!
>> Well, yes, I've always found US dates odd. I'm not a native speaker, so
>> I don't really know all the history. But in English, dates can be
>> written either "January 2" or "the 2nd of January". The number-only form
>> matches the first. I suppose this is because it's the more compact way
>> of expressing it, and americans tend to prefer compact and efficient.
>
> I suffix many of my file names by _yymmdd so files with otherwise identical names sort by date.
> Also used on handwritten note pages
> PDF files suffixed by author and year _nnn...yyyy
> Is there a windows utility that will sort directories using the last letters and digits in the file name?
>
> American, and have become more and more enamored of organizing stuff by date

See the Lifestreams project at

http://cs-www.cs.yale.edu/homes/freeman/lifestreams.html

From that page

> Lifestreams is built on a simple storage metaphor --- a time-ordered stream of documents combined with several powerful operators --- that replaces many conventional computer constructs (such as named files, directories, and explicit storage) and in the process provides a unified framework that subsumes many separate desktop applications to accomplish and handle personal communication, scheduling, and search and retrieval tasks.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

BGB <cr88192@gmail.com> schrieb:
> On 1/3/2022 6:14 PM, JimBrakefield wrote:
>> On Monday, January 3, 2022 at 12:33:26 PM UTC-6, Guillaume wrote:
>>> Le 03/01/2022 à 19:16, David Brown a écrit :
>>>> On 03/01/2022 18:21, MitchAlsup wrote:
>>>>> On Sunday, January 2, 2022 at 11:02:40 PM UTC-6, skybuck2000 wrote:
>>>>>> How do I know,
>>>>>>
>>>>>> My kitchen lamp died on 2-1-2022 lol.
>>>>> <
>>>>> Your kitchen lamp died on Feb 1, 2022 ?!? How prescient of you.
>>>>
>>>> Dates in most of the world are ordered more logically than the USA -
>>>> either day, month year, or year, month, day.
>>>>
>>>> Mind you, the PDP-endian US format gave us the international holidays of
>>>> Pi Day and Star Wars Day, so it has /some/ uses!
>>> Well, yes, I've always found US dates odd. I'm not a native speaker, so
>>> I don't really know all the history. But in English, dates can be
>>> written either "January 2" or "the 2nd of January". The number-only form
>>> matches the first. I suppose this is because it's the more compact way
>>> of expressing it, and americans tend to prefer compact and efficient.
>>
>> I suffix many of my file names by _yymmdd so files with otherwise identical names sort by date.
>> Also used on handwritten note pages
>> PDF files suffixed by author and year _nnn...yyyy
>> Is there a windows utility that will sort directories using the last letters and digits in the file name?
>>
>> American, and have become more and more enamored of organizing stuff by date
>
>
> I have typically used "YYYY-MM-DD", as it seemed obvious enough.

This is pretty much standard in companies here, you will find
many documents with file names starting with the date in this format.

This is also ISO 8601, I think.

Thomas Koenig <tkoenig@netcologne.de> writes:

> BGB <cr88192@gmail.com> schrieb:
>>
>> I have typically used "YYYY-MM-DD", as it seemed obvious enough.
>
> This is pretty much standard in companies here, you will find
> many documents with file names starting with the date in this format.

This is its compelling advantage: when you do a 'ls', it collates by
date.

> This is also ISO 8601, I think.

Yet another reason to use it.

On 1/6/2022 2:58 PM, Joe Pfeiffer wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>> BGB <cr88192@gmail.com> schrieb:
>>>
>>> I have typically used "YYYY-MM-DD", as it seemed obvious enough.
>>
>> This is pretty much standard in companies here, you will find
>> many documents with file names starting with the date in this format.
>
> This is its compelling advantage: when you do a 'ls', it collates by
> date.
>
>> This is also ISO 8601, I think.
>
> Yet another reason to use it.

This is a partial reason I do this.

Keeps tract of when I write things, and allows "sort by name" to
function as "sort by date written".

On Thursday, January 6, 2022 at 5:16:57 PM UTC-6, John Dallman wrote:
> In article <sqvehb$emn$1...@dont-email.me>, david...@hesbynett.no (David
> Brown) wrote:
>
> > Mind you, the PDP-endian US format gave us the international
> > holidays of Pi Day and Star Wars Day, so it has /some/ uses!
> Keeping the minutes for a weekly 'phone meeting between Brits and
> Americans, with a scattering of other nationalities, I found it useful to
> adopt the date format used by the US DoD, and VMS: today is 06-JAN-2022.
> It isn't anyone's native format, but everyone understands it.
<
This brings to mind that one can spell the name of the month (abbreviated)
and use any format without any reader error.
<
1-jan-1989
1-1981-jan
jan-1-1989
jan-1981-1
1981-1-jan
1981-jan-1
<
This solves the problem only in the places of the world using the Juliean Callendar, though....
>
> John

Joe Pfeiffer wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>> BGB <cr88192@gmail.com> schrieb:
>>>
>>> I have typically used "YYYY-MM-DD", as it seemed obvious enough.
>>
>> This is pretty much standard in companies here, you will find
>> many documents with file names starting with the date in this format.
>
> This is its compelling advantage: when you do a 'ls', it collates by
> date.

I use the same setup, with subdirs named using ISO datestamps, or in the
case of areas of interest, I'll do something like 2021_o for all the
orienteering-related stuff in 2021.

Instead of overwriting the big binary files which contains my
orienteering maps in OCAD format, I always save them with the map name
plus ISO data: Hvaler_2021-09-18.ocd.

This way I know I have a good previous copy if I discover a stupid
error, or if the file save process should crash (which has happened).
>
>> This is also ISO 8601, I think.
>
> Yet another reason to use it.
>
I switched to using ISO dates everywhere possible almost 40 years ago.
Back in Hydro we actually had two corporate standards: Norwegian
day/month/year and ISO YYYY-MM-DD. I was pretty much the only one who
actually used ISO, but I could at least point at the standards document
when people complained to me about my usage. :-)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

MitchAlsup wrote:
> On Thursday, January 6, 2022 at 5:16:57 PM UTC-6, John Dallman wrote:
>> In article <sqvehb$emn$1...@dont-email.me>, david...@hesbynett.no (David
>> Brown) wrote:
>>
>>> Mind you, the PDP-endian US format gave us the international
>>> holidays of Pi Day and Star Wars Day, so it has /some/ uses!
>> Keeping the minutes for a weekly 'phone meeting between Brits and
>> Americans, with a scattering of other nationalities, I found it useful to
>> adopt the date format used by the US DoD, and VMS: today is 06-JAN-2022.
>> It isn't anyone's native format, but everyone understands it.
> <
> This brings to mind that one can spell the name of the month (abbreviated)
> and use any format without any reader error.
> <
> 1-jan-1989
> 1-1981-jan
> jan-1-1989
> jan-1981-1
> 1981-1-jan
> 1981-jan-1
> <
> This solves the problem only in the places of the world using the Juliean Callendar, though....

And some form of ascii alphabet, i.e. they must be capable of reading
'jan/JAN' and understand it to mean "January in the Gregorian calendar".

Pure ISO numbers 2022-01-06 are even more universal.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Thursday, January 6, 2022 at 3:28:12 PM UTC-8, MitchAlsup wrote:
> On Thursday, January 6, 2022 at 5:16:57 PM UTC-6, John Dallman wrote:
> > In article <sqvehb$emn$1...@dont-email.me>, david...@hesbynett.no (David
> > Brown) wrote:
> >
> > > Mind you, the PDP-endian US format gave us the international
> > > holidays of Pi Day and Star Wars Day, so it has /some/ uses!
> > Keeping the minutes for a weekly 'phone meeting between Brits and
> > Americans, with a scattering of other nationalities, I found it useful to
> > adopt the date format used by the US DoD, and VMS: today is 06-JAN-2022.
> > It isn't anyone's native format, but everyone understands it.
> <
> This brings to mind that one can spell the name of the month (abbreviated)
> and use any format without any reader error.
> <
> 1-jan-1989
> 1-1981-jan
> jan-1-1989
> jan-1981-1
> 1981-1-jan
> 1981-jan-1
> <
> This solves the problem only in the places of the world using the Juliean Callendar, though....
> >
> > John

I didn't actually check, but I'm almost certain that an unsigned 128-bit integer can comfortably hold the age of our current era of a starry universe in nanoseconds, and that's pretty darned universal.

Michael Barry wrote:
> On Thursday, January 6, 2022 at 3:28:12 PM UTC-8, MitchAlsup wrote:
>> On Thursday, January 6, 2022 at 5:16:57 PM UTC-6, John Dallman
>> wrote:
>>> In article <sqvehb$emn$1...@dont-email.me>, david...@hesbynett.no
>>> (David Brown) wrote:
>>>
>>>> Mind you, the PDP-endian US format gave us the international
>>>> holidays of Pi Day and Star Wars Day, so it has /some/ uses!
>>> Keeping the minutes for a weekly 'phone meeting between Brits
>>> and Americans, with a scattering of other nationalities, I found
>>> it useful to adopt the date format used by the US DoD, and VMS:
>>> today is 06-JAN-2022. It isn't anyone's native format, but
>>> everyone understands it.
>> < This brings to mind that one can spell the name of the month
>> (abbreviated) and use any format without any reader error. <
>> 1-jan-1989 1-1981-jan jan-1-1989 jan-1981-1 1981-1-jan 1981-jan-1
>> < This solves the problem only in the places of the world using the
>> Juliean Callendar, though....
>>>
>>> John
>
> I didn't actually check, but I'm almost certain that an unsigned
> 128-bit integer can comfortably hold the age of our current era of a
> starry universe in nanoseconds, and that's pretty darned universal.

You need to measure in Planck time units, about 1e-43 seconds, needing
~150 bits/second, so I suggest 256-bit unsigned for true universality.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Michael Barry <barrym95838@yahoo.com> schrieb:
> On Thursday, January 6, 2022 at 3:28:12 PM UTC-8, MitchAlsup wrote:
>> On Thursday, January 6, 2022 at 5:16:57 PM UTC-6, John Dallman wrote:
>> > In article <sqvehb$emn$1...@dont-email.me>, david...@hesbynett.no (David
>> > Brown) wrote:
>> >
>> > > Mind you, the PDP-endian US format gave us the international
>> > > holidays of Pi Day and Star Wars Day, so it has /some/ uses!
>> > Keeping the minutes for a weekly 'phone meeting between Brits and
>> > Americans, with a scattering of other nationalities, I found it useful to
>> > adopt the date format used by the US DoD, and VMS: today is 06-JAN-2022.
>> > It isn't anyone's native format, but everyone understands it.
>> <
>> This brings to mind that one can spell the name of the month (abbreviated)
>> and use any format without any reader error.
>> <
>> 1-jan-1989
>> 1-1981-jan
>> jan-1-1989
>> jan-1981-1
>> 1981-1-jan
>> 1981-jan-1
>> <
>> This solves the problem only in the places of the world using the Juliean Callendar, though....
>> >
>> > John
>
> I didn't actually check, but I'm almost certain that an unsigned
> 128-bit integer can comfortably hold the age of our current era of a
> starry universe in nanoseconds, and that's pretty darned universal.

So where do you put t=0?

On 07/01/2022 11:39, Thomas Koenig wrote:
> Michael Barry <barrym95838@yahoo.com> schrieb:

>> I didn't actually check, but I'm almost certain that an unsigned
>> 128-bit integer can comfortably hold the age of our current era of a
>> starry universe in nanoseconds, and that's pretty darned universal.
>
> So where do you put t=0?
>

01.01.1970, for backwards compatibility. (I think that's how timestamps
on ext4 are done.)

Don't worry guys !

Normally I always write dates with the month name in it as:

2 january 2022 !

Just not this one time because I kinda looks funny.

Bye, Bye,
Skybuck ! =D

On Monday, January 3, 2022 at 6:02:40 AM UTC+1, skybuck2000 wrote:
> How do I know,
>
> My kitchen lamp died on 2-1-2022 lol.
>
> It's a message from some external universe.
>
> Let's see if it becomes true ! =D
>
> Bye,
> Skybuck.

BINGO:

https://jalopnik.com/honda-clocks-are-stuck-20-years-in-the-past-and-this-mi-1848306970

https://tech.slashdot.org/story/22/01/06/2225219/honda-clocks-are-stuck-20-years-in-the-past-and-there-isnt-a-fix

ONE COULD NOW ARGUE THAT MY PREDICTION HAS BECOME TRUE.

NOT ONLY THAT BUT IN A SPECTACULAR WAY.

JUST LIKE MY ORIGINAL HYPOTHESIS, WHICH WAS FOR THOSE THAT MISSED IT:

EXTERNALS COMMUNICATING WITH US THROUGH TIME/CLOCKS.

AND OH BOY HAVE THEY COMMUNICATED CLEARLY TO THIS POSTING OF MINE HAHAHAHAHAHA

CLOCKS OF HANDAS NOW STUCK ! LOLOLOLOLOL.

BYE,
SKYBUCK =D WOOOOOEEEEHOOEEEEEEEEE ! =D

It appears that Thomas Koenig <tkoenig@netcologne.de> said:
>> I didn't actually check, but I'm almost certain that an unsigned
>> 128-bit integer can comfortably hold the age of our current era of a
>> starry universe in nanoseconds, and that's pretty darned universal.
>
>So where do you put t=0?

October 23, 4004 BC, of course.

https://blogs.scientificamerican.com/history-of-geology/october-23-4004-bc-happy-birthday-earth/

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 1/7/2022 10:18 AM, John Levine wrote:
> It appears that Thomas Koenig <tkoenig@netcologne.de> said:
>>> I didn't actually check, but I'm almost certain that an unsigned
>>> 128-bit integer can comfortably hold the age of our current era of a
>>> starry universe in nanoseconds, and that's pretty darned universal.
>>
>> So where do you put t=0?

At zero, of course.

On Friday, January 7, 2022 at 12:20:20 PM UTC-6, Ivan Godard wrote:
> On 1/7/2022 10:18 AM, John Levine wrote:
> > It appears that Thomas Koenig <tko...@netcologne.de> said:
> >>> I didn't actually check, but I'm almost certain that an unsigned
> >>> 128-bit integer can comfortably hold the age of our current era of a
> >>> starry universe in nanoseconds, and that's pretty darned universal.
> >>
> >> So where do you put t=0?
> At zero, of course.
<
Creation of Earth zero or Big Bang zero ?