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
Hallo Tarion,
Environment.TickCount?
Das läuft auch weiter, wenn der Admin die Uhr umstellt.
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
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.
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
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.
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.
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