• Announcements

    • Robin

      Welcome!   03/05/2016

      Welcome, everyone, to the new 910CMX Community Forums. I'm still working on getting them running, so things may change.  If you're a 910 Comic creator and need your forum recreated, let me know and I'll get on it right away.  I'll do my best to make this new place as fun as the last one!
Illjwamh

This Day In History

Recommended Posts

3 hours ago, mlooney said:

Oct 25 seems to be the date for great military actions against overwhelming odds, yet winning the day.  Henry V at Agincourt, the Charge of the Light Brigade, the Battle off Samar.

While Agincourt and Samar fit your premise, I must assert that The Light Brigade failed to win the day

But in retreat, they did win Tennyson's admiration

Edited by Pharaoh RutinTutin
Spelling

Share this post


Link to post
Share on other sites
29 minutes ago, Pharaoh RutinTutin said:

While Agincourt and Samar fit your premise, I must assert that The Light Brigade failed to win the day

They did make it to the battery they were told to take out.  They did that.  They then retreated, so it wasn't a total victory, but it was, even if it was both a pyrrhic and hollow victory.  Not like Agincourt and Samar to be sure.

Share this post


Link to post
Share on other sites
6 minutes ago, mlooney said:

They did make it to the battery they were told to take out.  They did that.  They then retreated, so it wasn't a total victory, but it was, even if it was both a pyrrhic and hollow victory.  Not like Agincourt and Samar to be sure.

I suppose that I will now have to Google 'The Charge of the Light Brigade', because that makes no tactical sense. The nasty part is charging through the field of fire; once you are there, the cavalry has the advantage, and can take out the troops manning the artillery. Retreating would be suicide, another run through the field of fire. Even if they took horrendous losses in the charge, the remaining cavalry are better off hacking at those manning the guns.

(some minutes later) Per Wiki, that is pretty much what happened. The charge was the result of unclear orders to take out a smaller group retreating with captured cannons, and was misdirected at a defended redoubt. A remnant did reach their (revised) goal, but was so outmatched that they retreated, and were again subject to cannon fire, the only mitigating factor being that the enemy troops pursuing them were also fired upon.

Share this post


Link to post
Share on other sites
12 hours ago, mlooney said:

I was working tech support that night.  Nothing happened.  Now on 19 January 2038 Bad Things would happen...

I was on the mitigation crew the next day. We had prepped well, there was nothing much to clean up. As I recall the things most affected were various Java engines, and we had the replacements months ahead. IIRC, there was the official one from Sun, one from Microsoft, and one from IBM.

 

Share this post


Link to post
Share on other sites
2 hours ago, ijuin said:

I was never sure if it needed to be midnight UTC, or midnight local time.

The western celebration is celebrated relative to where you are, no? But like the song, It's Five O'Clock Somewhere says, there is a dateline that means it is already next year in many places east of each of us. At the International Dateline, New Years starts, and then is everywhere 23 hours later (or there about, some places do shorter increments).

I'm not tracking why UTC would be a defining characteristic of 'New Year' if you do not live in that time zone, anymore than 5 o'clock would be defined by 5 o'clock in UTC.

As I'm guessing you are aware, there are cultures that hold a different date as the new year, or count the years from a different date, or even scale the calendar year differently.

 

Share this post


Link to post
Share on other sites
20 minutes ago, Darth Fluffy said:

I'm not tracking why UTC would be a defining characteristic of 'New Year' if you do not live in that time zone, anymore than 5 o'clock would be defined by 5 o'clock in UTC.

I meant for the Y2k rollover issue. I was never certain whether UTC (i.e. international internet time) midnight or my local midnight was more important in terms of when my computer might choke on the year rollover.

Share this post


Link to post
Share on other sites
24 minutes ago, ijuin said:

I meant for the Y2k rollover issue. I was never certain whether UTC (i.e. international internet time) midnight or my local midnight was more important in terms of when my computer might choke on the year rollover.

Ah, that is an interesting question. Does my computer think in UTC and display local time, or does it think in offset time. I should probably know this, but I don't.

I can set my time as an offset from UTC, but that is based on how it is communicated. Hmm.

Share this post


Link to post
Share on other sites
9 hours ago, Darth Fluffy said:

Ah, that is an interesting question. Does my computer think in UTC and display local time, or does it think in offset time. I should probably know this, but I don't.

I can set my time as an offset from UTC, but that is based on how it is communicated. Hmm.

To the best of my knowledge,  modern computer's RTC is set to UTC and everything is adjusted via your timezone.  This is very much the case if you are getting your time "from the network" (i.e. NTP)  or from GPS.

Share this post


Link to post
Share on other sites
1 hour ago, mlooney said:

To the best of my knowledge,  modern computer's RTC is set to UTC and everything is adjusted via your timezone.  This is very much the case if you are getting your time "from the network" (i.e. NTP)  or from GPS.

That sounds right, as in, "That would be the best way to do it to ensure consistency". Broadcast time would not know where you are receiving, so UTC would make more sense. The receiver should know its own offset.

Share this post


Link to post
Share on other sites

Of course older MS-DOS based computers, not being networked as a general rule, the RTC was set to what ever random number you plugged in.  And, of course, some to them didn't have a battery for the clock, so you had to re-enter a time every time the power was turned off on the computer.

Share this post


Link to post
Share on other sites

Ah, but the question was about the behavior of a desktop or laptop running Windows 95 or 98 during the rollover from 1999 to 2000. Hardware and software standards not of that time period would not apply.

Share this post


Link to post
Share on other sites
18 minutes ago, ijuin said:

Ah, but the question was about the behavior of a desktop or laptop running Windows 95 or 98 during the rollover from 1999 to 2000. Hardware and software standards not of that time period would not apply.

The DOS (well, the bios and FAT file system) epoch started at Jan 1, 1980, and lasted until Dec 31 2099, so that shouldn't be a problem.  Windows itself has a an epoch of 1 January 1601 to 14 September 30,828.  Not sure when that took over the bios epoch, but in either case Jan 1, 2000 was not a problem.

 

Share this post


Link to post
Share on other sites
4 minutes ago, mlooney said:

The DOS (well, the bios and FAT file system) epoch started at Jan 1, 1980, and lasted until Dec 31 2099

We have to do the whole 1999 thing again in just 77 years?

Hardly seems worth getting out of your tomb each millenium

Share this post


Link to post
Share on other sites
15 minutes ago, Pharaoh RutinTutin said:

We have to do the whole 1999 thing again in just 77 years?

If some one is still using FAT file systems or IBM Bios calls in 2100 some thing has gone very wrong with the world.

Share this post


Link to post
Share on other sites
1 hour ago, ijuin said:

Yes, by then any system that isn’t over fifty years old ought to be running with 64 or 128 bit strings for timekeeping.

It's not strings, but bit width of signed integers.  64 bits is only an 8 character string, which really isn't enough to hold a time/date.

Share this post


Link to post
Share on other sites
6 hours ago, mlooney said:

It's not strings, but bit width of signed integers.  64 bits is only an 8 character string, which really isn't enough to hold a time/date.

UNIX-like operating systems (i.e. all currently-popular systems not based on DOS or Windows NT) record time as a count of seconds relative to 0:00:00 UTC on 1 January 1970. A 64-bit signed-integer timecount would allow for approximately 9.2 x 10^18 seconds, or 292 billion years.

Share this post


Link to post
Share on other sites
On 12/31/2021 at 6:40 PM, ijuin said:

I was never sure if it needed to be midnight UTC, or midnight local time.

That would depend on how your computer's clock was set.

At the time, the norm on Windows boxes was to set them to local time - so that's what would matter. (It also caused various issues every time "daylight savings time" started or stopped - mostly avoided by carefully never scheduling anything to start at a specific clock time between 1 and 3 AM local time.)

The norm on most other OSes, including Linux, was to set the computer's clock to UTC and also tell the OS what time zone you're in, and then treat the conversion to local date and time as a step in formatting for display (and ONLY when done for display - and if an app allowed a time entry, the app was expected to ask the OS to convert it to UTC, which is usually built into the bit of code that converts a string to a datetime). So on those systems UTC would be what mattered. (As for scheduling issues, just make sure everything is expected to be done at least an hour before it absolutely must be done, e.g. if your cash-register system has some overnight housekeeping that keeps the registers from operating until it's done, make sure it'll be complete at least an hour before the store opens.)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now