Laden...

Software Uhr die nicht die Systemzeit ist

Erstellt von Tarion vor 12 Jahren Letzter Beitrag vor 12 Jahren 1.565 Views
T
Tarion Themenstarter:in
381 Beiträge seit 2009
vor 12 Jahren
Software Uhr die nicht die Systemzeit ist

Hi,
DateTime.Now ist immer die aktuelle Systemzeit. Gibt es eine Möglichkeit eine Uhr zu nutzen die von der Systemzeit unabhängig ist?
Grund wäre, dass die Systemzeit nur mit Adminrechten verändert werden kann.

Natürlich kann man nur den Offset speichern und dann immer die gewünschte Zeit berechnen. Dann ist man aber weiterhin abhängig von der Systemzeit.

Gruß, Tarion

5.742 Beiträge seit 2007
vor 12 Jahren

Hallo Tarion,

Environment.TickCount?
Das läuft auch weiter, wenn der Admin die Uhr umstellt.

821 Beiträge seit 2009
vor 12 Jahren

Hallo Tarion,

Environment.TickCount?
Das läuft auch weiter, wenn der Admin die Uhr umstellt.

Wird diese Variable nicht nach jedem Neustart resettet?


@Tarion
Was willst du denn damit erreichen?
Wenn es sich um eine Anwendung handelt, die mit einem Server kommuniziert könntest du z.B. die Uhrzeit bei jedem Start der Anwendung übertragen und lokal hochzählen.

Ein anderer Ansatz wäre es Zeitserver zu verwenden: Zeitserver aus C# ansprechen

Gruß
Christoph

5.742 Beiträge seit 2007
vor 12 Jahren

Wird diese Variable nicht nach jedem Neustart resettet?

Ja - aber sie stellt die einzig, mir bekannte Möglichkeit dar, wirklich zuverlässig die Zeitdifferenz zwischen zwei Zeitpunkten zu berechnen.
Das Problem an der Sytemzeit ist ja - wie der OP angemerkt hat - dass sie vom Admin geändert werden kann und somit nicht zwangsläufig immer vorwärts geht.

Natürlich kann man nur den Offset speichern und dann immer die gewünschte Zeit berechnen. Dann ist man aber weiterhin abhängig von der Systemzeit.

...und in diesem Punkt kann man sozusagen nochmal unabhängig davon werden.

T
Tarion Themenstarter:in
381 Beiträge seit 2009
vor 12 Jahren

TickCount klingt super. Danke.

B
387 Beiträge seit 2005
vor 12 Jahren

Hallo Tarion,

aufpassen, ich selbst bin bei diesem Environment.TickCount schon einmal in die Falle getappt. Läuft deine Anwendung nämlich länger als 24,9 Tage durch, so fängt der Wert von TickCount wieder auf Int32.MinValue gesetzt.

Siehe Msdn

Der Wert dieser Eigenschaft wird über den Systemzeitgeber ermittelt und als 32-Bit-Ganzzahl mit Vorzeichen gespeichert. Wenn das System folglich ununterbrochen ausgeführt wird, wird TickCount von 0 (null) bis Int32.MaxValue für etwa 24,9 Tage erhöht und dann auf Int32.MinValue zurückgesetzt, der eine negative Zahl darstellt, um dann in den folgenden 24,9 Tagen zurück auf 0 erhöht zu werden.

Der Grund ist ganz einfach: Environment.TickCount ist vom Typ integer und kann damit keinen längeren Zeitraum speichern.

Gruß
Roland

T
Tarion Themenstarter:in
381 Beiträge seit 2009
vor 12 Jahren

Zur Genauigkeit kann man nicht viel sagen oder? Denke mal die Systemzeit basiert am Ende auch auf dem TickCount.

Mir geht es vor allem darum, dass ich meine Software aktuell als Admin starten muss um die Systemzeit mit einem Zeitserver synchronisieren kann. Da würde schon die Offsetlösung reichen. Es wird ohnehin in regelmäßigen Intervallen neu Synchronisiert.

Dann läuft die auch bei Benutzern die z.B. in der Firma keine Adminrechte haben.

T
Tarion Themenstarter:in
381 Beiträge seit 2009
vor 12 Jahren

Hallo Tarion,

aufpassen, ich selbst bin bei diesem Environment.TickCount schon einmal in die Falle getappt. Läuft deine Anwendung nämlich länger als 24,9 Tage durch, so fängt der Wert von TickCount wieder auf Int32.MinValue gesetzt.

Hier geht es um die System Up Time und nicht die Laufzeit des Programms. Aber den Überlauf bekommt man nicht so einfach mit oder?

Könnte natürlich bei jeder Abfrage des Datums eine If-abfrage machen und den abgefragten Wert speichern.

B
387 Beiträge seit 2005
vor 12 Jahren

Hi Tarion,

den Überlauf kriegt man nicht direkt mit, das ist richtig. Natürlich könnte man da etwas tricksen, aber ich denke, dass es für den Fall dann doch bessere Alternativen gibt. Die Frage ist, ob eine Laufzeit von 29,4 Tagen für dein Programm realistisch ist? Bei mir war es so, weil es sich um eine Dienstanwendung handelt, die idealerweise ewig durchläuft.

Mal ganz dumm gedacht: Wenn es nur darum geht, dass irgendein Timer immer nach oben geht, kann man ja auch einfach eine Stopwatch oder sowas am Anfang des Programms starten und dann einfach laufen lasst. Einen Überlauf oder ähnliches wird es da so schnell nicht geben. Und schlechter als mit Environment.TickCount bist du auch nicht.

Gruß
Roland

T
Tarion Themenstarter:in
381 Beiträge seit 2009
vor 12 Jahren

Stimmt, wäre ne 3. Alternative 😃 War auch nur aus Interesse.