DATE$ function

[eoredson]

Or set Date$="01-01-1980" and see when Windows sycns with the internet.

[SMcNeill]

Or set Date$="01-01-1980" and see when Windows sycns with the internet.

If you go into the registry, hunt for:  HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\W32Time\TimeProviders\NtpClient.

Right click on the SpecialPollInterval key, then click Modify.

That's the time -- in seconds -- between when syncing happens. You can set the date for 01-01-0001, and it won't matter. In XXXXX number of seconds, you'll sync and reset the time, or else a vast majority of windows based software won't work properly anymore.

[SMcNeill]

If you want to disable time syncing, simply go into Firewall and Disable UDP port 123 -- that's the one which Network Time Protocol uses to connect and sync times with.  (NTP Services)

[eoredson]

I just usually click Windows->Search and enter UAC then move slider up or down.

For time disable I goto ControlPanel->date/time->internet and decheck synch.

On a side note in Dosbox-X.conf config file I set:

synchronize time = true

to return host current time past midnight. because many time reports past system boot.

[mnrvovrfc]

SpriggsySpriggs I like your new avatar.

Um... to try to say something on topic, but I must have already. Feel lucky to be on Windows. Because any Unix will make it a PITA to change the time to try to fool something. Especially you can't be using a Linux distro like Arch Linux because "pacman" is very particular about GPG keys which have expiration dates and stuff like that. Gentoo with its "OpenRC" startup system likes ringing like a crow, "Clock skew detected!" and might give the user a hard time about setting the system clock "correctly".

Now I put "correctly" in double-quotation marks like that because I do not have the system time set shown by Windows, Slackware and a couple of other operating systems. It is set to UTC which satisfies only Debian and whatever is based on it. The time is a few hours off but having to read the "later" time from some reports is sometimes annoying. :/

[eoredson]

For certain purposes I might need to set the system date when it detects 01-01-1980 to 01-01-2079 and that date has arrived.

Where you have to reset the date to 2079 or earlier!? Of course I won't be alive then so I don't care... Plus some libraries won't detect past 2079 int.
ƒpdt=v

The overflow error will occur at 03:14:08 UTC on 19 January 2038. The problem exists in systems which measure Unix time – the number of seconds elapsed since the Unix epoch (00:00:00 UTC on 1 January 1970) – and store it in a signed 32-bit integer.

So, therefore, is a reason why I would need to set the system date.

https://en.wikipedia.org/wiki/Year_2038_problem

More stuff about time bugs:

https://en.wikipedia.org/wiki/Time_forma...and_65,536

[SpriggsySpriggs]

I sincerely doubt any QB64 program made today will be useful enough to be still in use in the year 2038. Definitely not in the year 2079...

[eoredson]

I sincerely doubt any QB64 program made today will be useful enough to be still in use in the year 2038. Definitely not in the year 2079...

I would have to agree. What really bugs me is that there might be 5-digit years

[Kernelpanic]

Reminds me of local forums where people kept popping up and wanting advice on how to turn off or delete this and that in order to save storage space - for hard drives with a terabyte or more.

These people almost always showed up after days or a few weeks with a cry for help: "My system suddenly crashed. I do not know why. How can I save my data (No backup, of course. They are experts!)?".

The world is full of experts, and they are not getting any less. 

[eoredson]

Alright: let's get weird on it and suppose this:

Code: (Select All)

Year 292,277,026,596
Certain problematic years occur so far in the future (well beyond the likely lifespan of the earth, the sun, humanity, and even past some predictions of the lifetime of the universe) that they are mainly referenced as matters of theoretical interest, jokes, or indications that a related problem is not truly solved for any reasonable definition of "solved".

The year 292,277,026,596 problem (about 2.9×1011 years in the future) will occur when the 64-bit Unix time overflows after UTC 15:30:08 on Sunday, 4 December, AD 292,277,026,596.