Skript übernimmt Systemzeit mit einer Stunde Verschiebung

[jmaus]

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 ?

Kommt drauf an aus welcher Perspektive du das siehst. Ich hatte ja erwähnt das die .Format() Funktion historisch bedingt keiner unterscheidung von zeitzonen kennt bzw. einfach nicht eine Unterscheidung zwischen lokaler und Weltzeit macht. D.h. egal welche Zeitdefinition du der Format() funktion gibst, sie wird die Zeit in lokale Zeit umwandeln und deshalb steht in deinem Beispiel auch 19 Uhr wohingegen Hour() 17 ausgibt weil "currenttime" eben definiert ist als die aktuelle zeit in UTC zeit und das ist nunmal localtime - 2 stunden im moment. Und das deine "timestring" zeile auch 19:24:18 statt 17:24:18 anzeigt ist dem geschuldet, das hier intern eben die exakt selbe Format() funktion aufgerufen wird und diese wie erwähnt eben keine unterscheidung von UTC vs. lokaler Zeit kennt und die Zeit die ihr gegeben wird immer in die lokale Zeit umwandelt.

Und das wird hoffentlich noch klarer wenn du jetzt einfach mal folgende Zeile ausprobierst:

Code: Alles auswählen

WriteLine (".Format():\t\t"#currenttime.Format("%c %Z")# "\t\t" + # currenttime.Format("%c %Z") );

Da kommt dann aktuell das hier raus:

Code: Alles auswählen

.Format():		Fri May  1 00:00:48 2020 CEST		Fri May  1 00:00:48 2020 CEST

Du siehst also das beides (currenttime + localtime) als Zeit in der CEST Zeitzone ausgegeben wird und das eben weil die Format() funktion immer nur die ihr gegebenen Zeiten in die lokale Zeitzone (hier eben CEST) umwandelt bzw. in der lokalen Zeitzone ausgibt. Insofern ist das meines Erachtens konsistent, wenn intuitiv schwer verständlich. Die IsLocalTime() funktion verrät aber eben das currenttime intern in der "Weltzeit" bzw. UTC gehalten wird und die Hour() Funktion gibt folglich auch richtig hier eine 17 aus weil die Hour(), Minute(), Second() funktion einfach roh das ausgibt wie die Zeit intern gehalten wird.

Nun könnte man natürlich argumentieren das Format() doch bitte (wenn die Zeit doch schon in Weltzeit gehalten wird) doch bitte auch hier die zeit in UTC ausgeben sollte. Das ist aber wie gesagt historisch so und da müsste man erst einmal schauen wie man das implementieren kann das es auch keine Nebeneffekte hat. Und dann muss man sich aber auch die frage nach dem "Warum" gefallen lassen, denn bis auf diesen Fall hier ist mir bis jetzt noch kein weiterer Fall oder Wunsch bekannt der Format() Funktion doch diese Unterscheidung beizubringen. Und dann müsste man auch schauen ob es nicht auch irgendwie Sinn ergibt das man Format() auch gleich zum Umwandeln/Ausgeben in der lokalen Zeit bewegen kann.

Hoffe damit ist es etwas klarer.

[Black]

es war jedenfalls verwirrend, wenn man sich den TimeString oder die Integer ansieht ist es passig, die ann um 0.15 Uhr angewandte Methode Weekday () auf currenttime brachte dann aber das Tagesbit des Vortages, damit war dann die Wochentagbestimmung des Offsets falsch.

es ist irritierend, man testet ein programm ja nicht kurz nach mitternacht um zu gucken, ob eine Wochentagkennung dann richtig ist.

Black

[alchy]

Kommt drauf an aus welcher Perspektive du das siehst.
...
Und das wird hoffentlich noch klarer
...
Hoffe damit ist es etwas klarer.

es ist doch immer wieder das Gleiche.
Habe ich dich gefragt, wie sich die RegaHss verhält?
oder
habe ich dich nach deiner Meinung gefragt, was richtig wäre?

Statt auf Deine simple Frage, was du selbst denn für richtig hältst zu antworten, schweifst du ab und erklärst mir lang und breit, was ich ja selbst kenne und sehe. Einfach nur schade, aber warum sollte sich das auch ändern.

weil "currenttime" eben definiert ist als die aktuelle zeit in UTC zeit und das ist nunmal localtime - 2 stunden im moment.

Danke. Und somit hat *IMHO* currenttime auch genau das auszugeben - Weltzeit - also 3x 17 Uhr. Alles andere ist falsch und ein Bug. Ende.

und dann muss man sich aber auch die frage nach dem "Warum" gefallen lassen,

Es einfach richtig machen? Einen Bug beseitigen?
Oder zählen doch nur die "medienwirksamen" Anfragen und Fehler in deinen Augen?

Aber wenn du schreibst

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

ist auch diese Aussage mehr als deutlich. Nur interessiert es niemanden.

Das ist aber wie gesagt historisch so und da müsste man erst einmal schauen wie man das implementieren kann das es auch keine Nebeneffekte hat.

Klar doch, weil dich das ja auch immer juckt.

Ein kleines Beispiel unter Vielen, z.B. die stillschweigende Änderung der Reaktion auf einen negativen Integerwert:
Aus:

wurde stillschweigend:

und aus die Maus.


Alchy

[jmaus]

weil "currenttime" eben definiert ist als die aktuelle zeit in UTC zeit und das ist nunmal localtime - 2 stunden im moment.

Danke. Und somit hat *IMHO* currenttime auch genau das auszugeben - Weltzeit - also 3x 17 Uhr. Alles andere ist falsch und ein Bug. Ende.

"currenttime" gibt gar nix aus, das ist weder ein Objekt noch eine Funktion. Es ist die Format() Funktion die wie gesagt keinerlei Unterscheidung zwischen lokaler und Weltzeit macht (egal ob für "currenttime" oder für ne eigene @XXXX@ zeit oder ähnliches). Es ist also kein Bug, sondern – wenn man hier eine Limitation sieht – einfach ein fehlendes Feature der Format() Funktion das es diese Unterscheidung zwischen lokaler Zeit und Weltzeit nicht macht. Auf der anderen Seite könnte man das ja auch als Feature verstehen das die Format() Funktion Zeiten die Ihr gegeben wird in lokale Zeit umwandlet bzw. ausgibt. D.h. wenn man die Funktion nun ändert damit es z.B. für currenttime die Zeit in UTC Zeit ausgibt so muss man IMHO trotzdem bedenken der Funktion z.B. einen zusätzlichen parameter zu geben damit man die Zeit trotzdem in lokaler Zeit ausgeben kann, wenn man das denn will/braucht.

[Black]

dafür das wir hier nun langsam aber sicher vom Thema abdriften...

wenn ich die Typecasts IntToBool von 4 programmiersprachen mal eben als Beispiel dazu nehme ergibt sich das Bild

in Python:

Code: Alles auswählen

Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 17:54:52) [MSC v.1900 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> bool (-1)
True
>>> bool (0)
False
>>> bool (1)
True
>>> 

in Javascript:

Code: Alles auswählen

log ("Test auf -1");
if (-1) {log ("true")} else {log ("false")}
log ("--------")
log ("Test auf -0");
if (0) {log ("true")} else {log ("false")}
log ("--------")
log ("Test auf 1");
if (1) {log ("true")} else {log ("false")}
log ("--------")

ergibt:

Code: Alles auswählen

javascript.2	2020-05-01 23:45:34.299	info	(14237) script.js.TestScript: registered 0 subscriptions and 0 schedules
javascript.2	2020-05-01 23:45:34.298	info	(14237) script.js.TestScript: --------
javascript.2	2020-05-01 23:45:34.298	info	(14237) script.js.TestScript: true
javascript.2	2020-05-01 23:45:34.298	info	(14237) script.js.TestScript: Test auf 1
javascript.2	2020-05-01 23:45:34.297	info	(14237) script.js.TestScript: --------
javascript.2	2020-05-01 23:45:34.297	info	(14237) script.js.TestScript: false
javascript.2	2020-05-01 23:45:34.297	info	(14237) script.js.TestScript: Test auf -0
javascript.2	2020-05-01 23:45:34.296	info	(14237) script.js.TestScript: --------
javascript.2	2020-05-01 23:45:34.296	info	(14237) script.js.TestScript: true
javascript.2	2020-05-01 23:45:34.295	info	(14237) script.js.TestScript: Test auf -1
javascript.2	2020-05-01 23:45:34.239	info	(14237) Start javascript script.js.TestScript
javascript.2	2020-05-01 23:45:28.285	info	(14237) received all states
javascript.2	2020-05-01 23:45:28.166	info	(14237) received all objects
javascript.2	2020-05-01 23:45:26.929	info	(14237) requesting all objects
javascript.2	2020-05-01 23:45:26.926	info	(14237) requesting all states
javascript.2	2020-05-01 23:45:26.836	info	(14237) starting. Version 4.5.1 in /opt/iobroker/node_modules/iobroker.javascript, node: v12.16.2, js-controller: 3.0.18
host.TestIOB10	2020-05-01 23:45:24.102	info	instance system.adapter.javascript.2 started with pid 14237

in c ergibt:

Code: Alles auswählen

int i = -1; //
bool b = (i ? true : false);
int i = 0; //
bool b = (i ? true : false);
int i = 1; //
bool b = (i ? true : false);

im Debugger das gleiche:
true
false
true

und in Pascal unter dem lazarus Compiler sehe ich auch das gleiche Bild:

eine CCU verhält sich mit aktueller Firmware genauso wie ich es von so ziemlich allen programmierspachen her kenne:

Anm. Variable ()liefert als ErgebnisTyp string und ein nicht leerer String ist true (egal ob 0 oder 1 drinsteht)


Black

[alchy]

"currenttime" gibt gar nix aus, das ist weder ein Objekt noch eine Funktion

Dann soll und muss es so sein wie es ist.
currenttime ist die Weltzeit und es ist ein Feature, das mit currenttime nicht die Weltzeit ausgegeben wird sondern die Lokalzeit.
Was für ein Wahnsinns Feature !

dafür das wir hie rnun langsam aber sicher vom Thema abdriften..

Du hast nicht mal begriffen, was ich geschrieben habe. Es ging nicht darum, ob es woanders auch so ist.

Alchy

[Black]

Du hast nicht mal begriffen, was ich geschrieben habe. Es ging nicht darum, ob es woanders auch so ist.
Alchy

ich denke mal schon ....

[Uwe-S]

Prima, ich mache jetzt mal als "Nicht-Programmierer" wieder mit. Da ich nicht kapiere, worüber ihr eigentlich streitet, teile ich einfach mal meine Beobachtungen mit. Also, um eine Stunde den Programmablauf nach hinten zu verschieben (also auf 1:30Uhr) reicht nicht, Rollläden gehen trotzdem falsch auf. Wie ich jetzt aber so rausgelesen habe in eurem Streitgespräch, muss ich wohl mind. 2 Stunden nach 0:00Uhr berechnen lassen, damit ich den richtigen Tag erwische. Ist das richtig so?
Oder aber auf localtime umstellen.

[Black]

Eine Stunde würde reichen in Winterzeit. Immo ist 2 stunden Differenz zu utc drum hat die eine Stunde nicht gereicht.

Nimml ocaltime dann sollte es passen. Ich habe in meinem threat auch schon geändert.

Black

[jmaus]

Wie ich jetzt aber so rausgelesen habe in eurem Streitgespräch, muss ich wohl mind. 2 Stunden nach 0:00Uhr berechnen lassen, damit ich den richtigen Tag erwische. Ist das richtig so?
Oder aber auf localtime umstellen.

Du musst auf "localtime" Nutzung umstellen oder die Zeit ist beim nächsten Sommer->Winterzeitwechsel wieder falsch, denn dann sind es nur 1 Std. unterschied zur UTC zeit.