Skript übernimmt Systemzeit mit einer Stunde Verschiebung

[Uwe-S]

So, nun jetzt erst wieder. Blöde Schichtarbeit.
Hatte ich mir auch schon überlegt, den Programmablauf um eine Stunde zu verschieben. Habe nun doch leider versäumt, das Ganze zu protokollieren. Ich übernehme deine Vorschläge in den nächsten 2 Wochen mal einzeln, um zu sehen, wann sich eine Änderung einstellt.
Die Rollläden liefen am Samstag und heute auch wieder zur falschen Zeit hoch.
Ich teste mal weiter, davon stirbt ja niemand.
Trotzdem erst mal vielen Dank.

[Black]

Ich denke, dass die Bestimmung der Zusatzfunktion, wo du mit weekday () auf Samstag Sonntag Prüfstand zu dem Zeitpunkt der Prüfung noch einen Tag zurück bist, deshalb Samstag falsch da wird Freitag gefahren, Sonntag stimmt, da wird Samstag genommen und die sind gleich, montag falsch da Sonntag genommen wird.

Wenn du die berechnungszeit auf später 1.01 legst wird das wieder passen.

Ich schau mir trotzdem mal das ganze an.

Black

[Black]

Ich habs mir angeschaut.. Nun isses auch klar, es gibt einen kleinen, aber bösartigen Unterschied, vllt sogar Bug zwischen localtime und currenttime. Vllt kann da Jens dann auch mal reinschauen.

Offensichtlich sehen beide im ersten Moment gleich aus... im ersten Moment.

folgendes kleines Testprogramm:

Code: Alles auswählen

WriteLine ("currenttime\t\tlocaltime")
WriteLine (currenttime # "\t" # localtime);
WriteLine (currenttime.ToInteger () # "\t\t" # localtime.ToInteger () );
WriteLine (currenttime.Hour ()#":" # currenttime.Minute ()# ":" # currenttime.Second () # "\t\t" + localtime.Hour () #":" # currenttime.Minute ()# ":" # currenttime.Second () );
WriteLine (currenttime.IsDST () # "\t\t\t" # localtime.IsDST () );
WriteLine (currenttime.IsLocalTime () # "\t\t\t" # localtime.IsLocalTime () );      

bringt folgende Ausgabe:

heisst also: die Methode an sich und To int bringen die GLEICHEN Werte an der zeit
ABER

Einzelmethoden wie Stunde, Minuten, Sekunden bringen zutage:
currenttime is wohl zulu zeit, localtime die locale zeit inc Sommerzeit. hübsch....., wäre aber schön, wenn die Zeitausgabe auch diesen Unterschied hervorgringen würde.

Nun zu deinem Problem: wenn du um 0:15 oder auch 1:15 triggerst, bringt currenttime.WeekDay () den Wochentag zur Zuluzeit, die dann bei 22:15 bzw 23:15 liegt und die die Wochentagkennung des Vortages bringt. Damit geht natürlich die Wochenendkennung daneben:

korrigiere bitte currenttime gegen localtime, dann müsste es passen, ich habs in meinem Threat auch schon angepasst


Gruss, Black

[emil70]

@Black

Kannst du mal ein Link zum deinem Threat hier reinmachen

danke

[Black]

@Black
Kannst du mal ein Link zum deinem Threat hier reinmachen
danke

Klar Kann ich

Howto - AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens

Gruss, Black

[jmaus]

Ich habs mir angeschaut.. Nun isses auch klar, es gibt einen kleinen, aber bösartigen Unterschied, vllt sogar Bug zwischen localtime und currenttime. Vllt kann da Jens dann auch mal reinschauen.

Also ich kann in der Ausgabe nichts falsches erkennen oder gar einen Bug sehen. Auch die Ausgabe von ToInteger() is vollkommen korrekt, denn die Unix Zeit ist immer als UTC zeit definiert. Und die Unixzeit ist in allen Zeitzonen fortlaufend. ToInteger() gibt also die gleiche Unixzeit überall in der Welt zur exakt gleichen Zeit aus. Stimmt also alles soweit.

[Black]

Ok... hab ich mich da verrannt. Ist jedenfalls im zugehörigen Thread geändert und sollte nun tun.

Thx, black

[alchy]

Also ich kann in der Ausgabe nichts falsches erkennen oder gar einen Bug sehen.

Bitte, vielleicht doch jetzt endlich noch mal genauer hinschauen?
Leider hast du ja auch schon BadenPowers Hinweise bezüglich Zeitumstellung ignoriert. Da grüsst man hiermit doch gerne die Mitleser.

Auch die Ausgabe von ToInteger() is vollkommen korrekt, denn die Unix Zeit ist immer als UTC zeit definiert. Und die Unixzeit ist in allen Zeitzonen fortlaufend.

Abgesehen vom "Auch" am Anfang des Satzes, volle Zustimmung. Aber wir wollen nicht kleinlich sein.
Versuchen wir es mit einer durchaus ernst gemeinten Frage:
Was soll deiner Meinung denn nun richtig sein?
die Stundenangabe direkt aus currenttime oder die Stunden aus currenttime die mittels . Hour() ausgegeben werden ?
Zusatzfrage: Oder vielleicht doch besser die, welche mittels .Format() aus currenttime ermittelt werden?

Alchy

[jmaus]

Auch die Ausgabe von ToInteger() is vollkommen korrekt, denn die Unix Zeit ist immer als UTC zeit definiert. Und die Unixzeit ist in allen Zeitzonen fortlaufend.

Abgesehen vom "Auch" am Anfang des Satzes, volle Zustimmung. Aber wir wollen nicht kleinlich sein.
Versuchen wir es mit einer durchaus ernst gemeinten Frage:
Was soll deiner Meinung denn nun richtig sein?
die Stundenangabe direkt aus currenttime oder die Stunden aus currenttime die mittels . Hour() ausgegeben werden ?
Zusatzfrage: Oder vielleicht doch besser die, welche mittels .Format() aus currenttime ermittelt werden?

Ach du spielst darauf an, das ein .Format() von "currenttime" und "localtime" die selbe Ausgabe liefert? Das ist in der Tat so, war aber auch schon immer so und ist einfach dem geschuldet das die .Format() Funktion keine unterscheidung zwischen lokaler zeit und GMT/UTC zeit macht und einfach hart jegliche Zeiten in die lokale zeit umwandelt. Es ist also so, das .Hour() und .IsLocalTime() hier vollkommen korrekte werte ausgeben, lediglich die Ausgabe von .Format() für currenttime bzw. eine Zeit ausserhalb der lokalen Zeitzone ist nicht das was man bzw. du vmtl. erwartet. Aber auf der anderen Seite hat bis jetzt auch noch niemand in praktischer weise wohl vermisst das die .Format() Funktion keine Unterscheidung zwischen lokaler Zeit und UTC/GMT Zeit macht und die Frage wäre nun welche möglichen Auswirkungen bzw. Nebeneffekte es hätte wenn ich der Format() Funktion jetzt diese Möglichkieit beibringe. Das muss ich mir einfach mal etwas näher anschauen bevor ich das umsetze.

[alchy]

Herrgott noch mal.
Ich spiele nicht an. Ich hatte dir eine Frage gestellt, welche du wohl augenscheinlich nicht beantworten willst.
Nehmen wir doch das Beispiel von oben, ein wenig erweitert.

Code: Alles auswählen

WriteLine ("\t\t\tcurrenttime\t\tlocaltime")
WriteLine ("timestring:\t\t"#currenttime # "\t" # localtime);
WriteLine ("integer:\t\t"#currenttime.ToInteger () # "\t\t" # localtime.ToInteger () );
WriteLine (".Hour():\t\t"#currenttime.Hour ()#":" # currenttime.Minute ()# ":" # currenttime.Second () # "\t\t" #localtime.Hour () #":" # currenttime.Minute ()# ":" # currenttime.Second () );
WriteLine (".Format():\t\t"#currenttime.Format("%H")#":" # currenttime.Format("%M")# ":" # currenttime.Format("%S") # "\t\t" + localtime.Format("%H") #":" # currenttime.Format("%M")# ":" # currenttime.Format("%S") );
WriteLine ("Sommerzeit:\t\t"#currenttime.IsDST () # "\t\t\t" # localtime.IsDST () );
WriteLine ("Localzeit:\t\t"#currenttime.IsLocalTime () # "\t\t\t" # localtime.IsLocalTime () ); 

ergibt:

Code: Alles auswählen

			currenttime		localtime
timestring:		2020-04-30 19:24:18	2020-04-30 19:24:18
.Tointeger:		1588267458		1588267458
Methode Hour():		17 Uhr+			19 Uhr+ 
Methode Format():	19 Uhr+			19 Uhr+
Sommerzeit Flag:	0			1
Localzeit Flag:		0			1

So wie die Flags sitzen, sollte nun deiner Meinung nach in der currenttimespalte 3x 17 oder 19 Uhr stehen oder ein Mischmasch ?

Alchy