Anti Time-Travel - Revision history

Ryccardo: format of offset

2016-07-23T08:48:44Z

format of offset

← Older revision		Revision as of 12:48, 23 July 2016
Line 5:		Line 5:
	The hardware RTC can count between (at least) 2001-1-1 and 2050-12-31.		The hardware RTC can count between (at least) 2001-1-1 and 2050-12-31.

	~~<del>~~When the time is normally set, ~~the date in the RTC is set to the start of 2001 (''and so is the time?''), and</del> (not always correct)~~ the console saves to the [[Config Savegame]] the ~~time and date~~ difference between the actual time and the RTC value.		When the time is normally set, the console saves to the [[Config Savegame]] the number of seconds of difference between the actual time and the RTC value.

	:This also explains the apparently random setting of the date after removing the battery, and why adjusting the clock in [[NAND Redirection\|multiboot scenarios]] often results in incorrect values in other OS instances.		:This also explains the apparently random setting of the date after removing the battery, and why adjusting the clock in [[NAND Redirection\|multiboot scenarios]] often results in incorrect values in other OS instances.

	Most likely, software disturbed by clock adjustments saves the raw RTC value and, on load, checks whether it has advanced. [[3DS Development Unit Software\|CONFIG]] can directly adjust the hardware clock, thus avoiding associated problems.		Most likely, software disturbed by clock adjustments saves the raw RTC value and, on load, checks whether it has advanced. [[3DS Development Unit Software\|CONFIG]] can directly adjust the hardware clock, thus avoiding associated problems.

Ryccardo: new information

2016-06-15T12:45:39Z

new information

← Older revision		Revision as of 16:45, 15 June 2016
Line 5:		Line 5:
	The hardware RTC can count between (at least) 2001-1-1 and 2050-12-31.		The hardware RTC can count between (at least) 2001-1-1 and 2050-12-31.

	When the time is normally set, the date in the RTC is set to the start of 2001 (''and so is the time?''), and the console saves to ~~NAND (''where?'')~~ the time and date difference between the ~~programmed~~ time and the ~~hardware one~~.		<del>When the time is normally set, the date in the RTC is set to the start of 2001 (''and so is the time?''), and</del> (not always correct) the console saves to the [[Config Savegame]] the time and date difference between the actual time and the RTC value.

	:This also explains the apparently random setting of the date after removing the battery, and why adjusting the clock in [[NAND Redirection\|multiboot scenarios]] often results in incorrect values in other OS instances.		:This also explains the apparently random setting of the date after removing the battery, and why adjusting the clock in [[NAND Redirection\|multiboot scenarios]] often results in incorrect values in other OS instances.

	Most likely, software disturbed by clock adjustments saves the raw RTC value and, on load, checks whether it has advanced. [[3DS Development Unit Software\|CONFIG]] can directly adjust the hardware clock, thus avoiding associated problems.		Most likely, software disturbed by clock adjustments saves the raw RTC value and, on load, checks whether it has advanced. [[3DS Development Unit Software\|CONFIG]] can directly adjust the hardware clock, thus avoiding associated problems.

LIT at 11:22, 20 April 2016

2016-04-20T09:22:59Z

← Older revision		Revision as of 13:22, 20 April 2016
Line 9:		Line 9:
	:This also explains the apparently random setting of the date after removing the battery, and why adjusting the clock in [[NAND Redirection\|multiboot scenarios]] often results in incorrect values in other OS instances.		:This also explains the apparently random setting of the date after removing the battery, and why adjusting the clock in [[NAND Redirection\|multiboot scenarios]] often results in incorrect values in other OS instances.

	Most likely, software disturbed by clock adjustments saves the raw RTC value and, on load, checks whether it has advanced. [[3DS Development Unit Software\|CONFIG]] can directly adjust the ~~ahrdware~~ clock, thus avoiding associated problems.		Most likely, software disturbed by clock adjustments saves the raw RTC value and, on load, checks whether it has advanced. [[3DS Development Unit Software\|CONFIG]] can directly adjust the hardware clock, thus avoiding associated problems.

Ryccardo: Clock software stack documentation

2016-04-18T19:21:15Z

Clock software stack documentation

New page

Many commercial games, such as Tomodachi Life, all Pokèmon games, etc are capable of '''telling whether the clock was adjusted''' while they weren't running, '''even for realistic progress of time''' (new setting in the future from last save).

This is achieved through a peculiarity in the implementation of the real time clock.

The hardware RTC can count between (at least) 2001-1-1 and 2050-12-31.

When the time is normally set, the date in the RTC is set to the start of 2001 (''and so is the time?''), and the console saves to NAND (''where?'') the time and date difference between the programmed time and the hardware one.

:This also explains the apparently random setting of the date after removing the battery, and why adjusting the clock in [[NAND Redirection|multiboot scenarios]] often results in incorrect values in other OS instances.

Most likely, software disturbed by clock adjustments saves the raw RTC value and, on load, checks whether it has advanced. [[3DS Development Unit Software|CONFIG]] can directly adjust the ahrdware clock, thus avoiding associated problems.