[FHEM-devel] RfP: Untereintraege von Readings

[Dr. Boris Neubert]

Hallo,

in fhem 4.x sieht der Readings-Container so aus:

$defs{DeviceName}{READINGS}{TheReading}{TIME}= Zeit im Format YYYY-MM-DD
hh:mm:ss
$defs{DeviceName}{READINGS}{TheReading}{VAL}= irgendwas
modulspezifisches, ggf. mehrere Werte und mit Einheiten

Jetzt sollten wir zu folgenden Punkten eine Entscheidung zu treffen:

1. In welchem Format soll die Zeit abgespeichert werden?
a. menschenlesbar (wie in fhem 4.x)
b. maschinenlesbar
c. beides (zwei Untereintraege)

2. Nur genau ein Wert ohne Einheit im VAL-Feld?
also: "23" statt "T: 23 (Celsius)"

3.Verwendete Einheit:
a. ergibt sich aus der Dokumentation
b. ergibt sich indirekt aus der Dokumentation einer irgendwie
gearteten Interfacespezifikation
(Gerät ist ein Thermometer -> es gibt ein Reading "Temperature"
und das ist immer in °C)
c. ergibt sich aus einem expliziten Untereintrag
$defs{DeviceName}{READINGS}{TheReading}{UNIT}="°C"

Separate Themen, die hier in diesem Thread ausgeklammert werden:
- UTC vs. Local Time
- Format für maschinenlesbare Zeit
- Time oder Tim, Val oder Value u.ae.


Zu 1. plädiere ich für maschinenlesbar, weil die Darstellung im
Frontend/für den Benutzer abhängig von der LOCALE sein sollte.
Zu 2. plädiere ich für ja, weil sich das viel einfacher in
Logdefinitionen und Frontends auswerten läßt
Zu 3. plädiere ich für c., weil man dann sieht, was Sache ist, und man
auch noch flexibler ist.

Grüße,
Boris

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM developers beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-de...@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-develope...@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-developers?hl=de, um weitere Optionen zu erhalten.

[Axel]

Hallo Boris,

kurz:
1. -> b
2. -> Ja
3. -> c

Schöne Grüße

Axel

[Rudolf Koenig]

> Zu 1. plädiere ich für maschinenlesbar, weil die Darstellung im
> Frontend/für den Benutzer abhängig von der LOCALE sein sollte.

Einverstanden, obwohl eine "Maschine" das menschenlesbare auch gut lesen kann.
Will nur nochmal erwaehnen, da dies viel Arbeit, und nicht sehr viel Nutzen
bringen wird. Ich hoffe, dass ich nicht alleine bleibe bei der Umsetzung.

Kleiner Ausflug: Wie sollen die einzelnen Kommandos/Module die Daten ausgeben?
Vorschlag:
- "list" und "xmllist" menschenlesbar wie bisher, mit Option fuer
maschinenlesbar.
- save (statefile) maschinenlesbar
- FileLog weiterhin menschenlesbar. Falls jemand das will, dann mit Attribut
fuer Maschinenlesbar.

> Zu 2. plädiere ich für ja, weil sich das viel einfacher in
> Logdefinitionen und Frontends auswerten läßt

Ok.

> Zu 3. plädiere ich für c., weil man dann sieht, was Sache ist, und man
> auch noch flexibler ist.

Bin dann auch fuer c (aber noch sehr leicht fuer a zu ueberzeugen :) Ich
moechte aber statt °C lieber C oder Celsius, damit wir wenigstens hier in ASCII
bleiben.

[Kai 'wusel' Siering]

Moin,

Dr. Boris Neubert wrote:

> in fhem 4.x sieht der Readings-Container so aus:
>
> $defs{DeviceName}{READINGS}{TheReading}{TIME}= Zeit im Format YYYY-MM-DD hh:mm:ss
> $defs{DeviceName}{READINGS}{TheReading}{VAL}= irgendwas
> modulspezifisches, ggf. mehrere Werte und mit Einheiten
>
> Jetzt sollten wir zu folgenden Punkten eine Entscheidung zu treffen:
>
> 1. In welchem Format soll die Zeit abgespeichert werden?
> a. menschenlesbar (wie in fhem 4.x)
> b. maschinenlesbar
> c. beides (zwei Untereintraege)

Maschinenlesbar, ggf. normierte Hilfsfunktionen für menschengerechte Darstellung.

> 2. Nur genau ein Wert ohne Einheit im VAL-Feld?
> also: "23" statt "T: 23 (Celsius)"

Nur ein Wert, ohne Einheit. Festlegung einer normierten Einheit, die ver-
wendet wird (klare Präferenz: °C oder K für Temperaturwerte) erübrigt
die Angabe. Ggf. wieder Hilfsfunktion zur Einheitenumrechnung.

> 3.Verwendete Einheit:
> a. ergibt sich aus der Dokumentation
> b. ergibt sich indirekt aus der Dokumentation einer irgendwie
> gearteten Interfacespezifikation
> (Gerät ist ein Thermometer -> es gibt ein Reading "Temperature"
> und das ist immer in °C)
> c. ergibt sich aus einem expliziten Untereintrag
> $defs{DeviceName}{READINGS}{TheReading}{UNIT}="°C"

Es fehlt:

d. ergibt sich aus Festlegung gem. "FHEM-Standard".

Problem sind neue Meßgrößen, aber i. d. R. gibt es für alles Relevante
eine SI-Einheit, die im Zweifel als Fallback definiert sein könnte.

Varianten a & b lassen Raum für Mißverständnisse, c bürdet für jeden
Zugriff auf die Werte jeder Anwendung einen zweiten Lookup auf, der
komplett überflüssig ist, wenn man derlei vorab definiert. Daher d.
kai

[Andy Fuchs]

Am 18.04.2010 um 09:37 schrieb Rudolf Koenig <inf...@koeniglich.de>:

>> Zu 1. plädiere ich für maschinenlesbar, weil die Darstellung im
>> Frontend/für den Benutzer abhängig von der LOCALE sein sollte.

Ich bin ebenfalls für maschinenlesbar.
M.e. Hat das einige Vorteile, angefangen bei der Eindeutigkeit über Genauigkeit bis hin zum geringeren Speicherverbrauch. Umrechnen muss man im Frontend meist sowieso (zumindest in irgendein ISO, oder länderspezifisches Format).

> Einverstanden, obwohl eine "Maschine" das menschenlesbare auch gut lesen kann.
> Will nur nochmal erwaehnen, da dies viel Arbeit, und nicht sehr viel Nutzen
> bringen wird. Ich hoffe, dass ich nicht alleine bleibe bei der Umsetzung.
>
> Kleiner Ausflug: Wie sollen die einzelnen Kommandos/Module die Daten ausgeben?
> Vorschlag:
> - "list" und "xmllist" menschenlesbar wie bisher, mit Option fuer
> maschinenlesbar.
> - save (statefile) maschinenlesbar
> - FileLog weiterhin menschenlesbar. Falls jemand das will, dann mit Attribut
> fuer Maschinenlesbar.

Das würde ich ebenfalls unterschreiben. So hat man beides. Gerade im Filelog finde ich das wichtig, aber natürlich auch sonst.

Andy

[Dr. Boris Neubert]

Hallo,

ich habe den Stand dieser Diskussion wieder zusammengefasst und
Entscheidungsvorlagen formuliert. Dabei habe ich weitere in der
Diskussion angesprochene oder verwandte Themen ergaenzt. Siehe E5 bis
E10 in http://www.fhemwiki.de/index.php/DevelopmentGuidelines.

Hinweise zur weiteren Diskussion:
- E5 bezieht maschinenlesbar grundsaetzlich auf ALLE Zeiten in fhem.
- E6 ist ein neuer Aspekt.
- E7 Vorschlaege fuer das Format der maschinenlesbaren Zeit gesucht.
- E9 noch nicht ausreichend besprochen.
- E10 ist ein neuer Aspekt.

Viele Gruesse,

[Andy Fuchs]

On 24.04.10 19:33, "Dr. Boris Neubert" <om...@online.de> wrote:

> - E5 bezieht maschinenlesbar grundsaetzlich auf ALLE Zeiten in fhem.

Ich bin für 'maschinenlesbar' oder 'sowohl als auch'.

> - E6 ist ein neuer Aspekt.

Ja

> - E7 Vorschlaege fuer das Format der maschinenlesbaren Zeit gesucht.

String. (Zahl zu String)

> - E9 noch nicht ausreichend besprochen.

Hat fhem überhaupt die Möglichkeit herauszubekommen, ob das jeweilige Gerät
Celsius oder sonstwas ausgibt? Falls nicht, wäre die Einheiten-Definitionen
m.E. eigentlich Geräte-Attribute.

> - E10 ist ein neuer Aspekt.

UTF-8


btw. arbeitest Du eigentlich mit einer amerikanischen Tastatur, oder sind
bei Dir die Umlaut-Tasten kaputt? ;-)

Grüße

andy

[Dr. Boris Neubert]

Hallo,

Andy Fuchs schrieb:

>> - E7 Vorschlaege fuer das Format der maschinenlesbaren Zeit gesucht.
>
> String. (Zahl zu String)
>

Ich war in meiner Frage nicht praezise genug. Verwenden wir time, also
die Anzahl der Sekunden seit 01.01.1970 00:00:00 UTC in Unix bzw. 1904
in MacOS? Damit waere dann auch gleich die Frage nach der Zeitzone
beantwortet.

> btw. arbeitest Du eigentlich mit einer amerikanischen Tastatur, oder sind
> bei Dir die Umlaut-Tasten kaputt? ;-)

US-Layout (viel komfortabler zum Programmieren, weil die wichtigen
Zeichen dann ohne Modifier Keys erzeugt werden koennen) i.V.m. Faulheit,
das Layout umzustellen. :-)

Gruesse,
Boris

[Andy Fuchs]

On 26.04.10 20:31, "Dr. Boris Neubert" <om...@online.de> wrote:

> Hallo,
>
> Andy Fuchs schrieb:
>>> - E7 Vorschlaege fuer das Format der maschinenlesbaren Zeit gesucht.
>>
>> String. (Zahl zu String)
>>
>
> Ich war in meiner Frage nicht praezise genug. Verwenden wir time, also
> die Anzahl der Sekunden seit 01.01.1970 00:00:00 UTC in Unix bzw. 1904
> in MacOS? Damit waere dann auch gleich die Frage nach der Zeitzone
> beantwortet.

Ich wäre für UTC.

>> btw. arbeitest Du eigentlich mit einer amerikanischen Tastatur, oder sind
>> bei Dir die Umlaut-Tasten kaputt? ;-)
>
> US-Layout (viel komfortabler zum Programmieren, weil die wichtigen
> Zeichen dann ohne Modifier Keys erzeugt werden koennen) i.V.m. Faulheit,
> das Layout umzustellen. :-)

Dachte ich mir schon, aber im Wiki fände ich es insgesamt schöner... Das
Auge liest bekanntlich mit ;-)

a.

[Kai 'wusel' Siering]

Dr. Boris Neubert wrote:
> Hallo,
>
> ich habe den Stand dieser Diskussion wieder zusammengefasst und
> Entscheidungsvorlagen formuliert. Dabei habe ich weitere in der
> Diskussion angesprochene oder verwandte Themen ergaenzt. Siehe E5 bis
> E10 in http://www.fhemwiki.de/index.php/DevelopmentGuidelines.
>
> Hinweise zur weiteren Diskussion:
> - E5 bezieht maschinenlesbar grundsaetzlich auf ALLE Zeiten in fhem.

Ich würde die Ausnahmen, auch gegen den Wunsch von Rudi, streichen. Intern
alles maschienenlesbar (bei Speichern: ASCII-Repräsentation, um Big-/Little-
endianess zu umgehen), bei "list" würde ich einen Menschenbezug sehen (also
Mach2Human(time)), bei "xmllist" diesen explizit NICHT. FileLog ... dunno,
sehe ich aber keinen Menschenbezug ... andererseits sind traditionelle Logs
ja NUR für Menschen da ;)

> - E7 Vorschlaege fuer das Format der maschinenlesbaren Zeit gesucht.

Irgendwas, womit man einfach rechnen kann (time_t, also Sekunden seit X,
wäre cool, aber die Unix-Variante ist IIRC nur 32bittig und rotiert in
2038 auf 0), möglichst ohne groß Umrechnungsroutinen zu nutzen (Negativ-
beispiel ist dieses TAI64 oder so, was qmail in Logs nutzt ... Genau wie
'ne Atomuhr und mindestens so handlich ...).

> - E9 noch nicht ausreichend besprochen.

Was fehlt da noch?

> - E10 ist ein neuer Aspekt.

Da wir eh' alles über'n Haufen werfen, wäre ich für UTF-8, ack. Wobei ich
momentan nichts fände, wo mehr als US-ASCII benutzt würde -- oder aufgrund
anderer Beschränkungen (perl?) könnte. Insofern wäre ein Anlehnung an die
Sprache, i. e. perl, sinnvoll.
kai

[Kai 'wusel' Siering]

Dr. Boris Neubert wrote:

> Andy Fuchs schrieb:
>>> - E7 Vorschlaege fuer das Format der maschinenlesbaren Zeit gesucht.
>>
>> String. (Zahl zu String)
>
> Ich war in meiner Frage nicht praezise genug. Verwenden wir time, also
> die Anzahl der Sekunden seit 01.01.1970 00:00:00 UTC in Unix bzw. 1904
> in MacOS? Damit waere dann auch gleich die Frage nach der Zeitzone
> beantwortet.

Wieso ist damit die Frage nach der Zeitzone beantwortet? Zeitzone UTC wäre
generell sinnvoll, wobei natürlich auch die lokale Zeitzone einen gewissen
Charme hat. Ich bin hier unentschlossen, prinzipiell sollte es UTC sein und
jeglichen Datumskonvertierung Aufgabe des jeweiligen Frontends sein.

Unix' time_t läuft IIRC im Frühjar 2038 über, latent verbietet sichdessen
Nutzung für neue Anwendungen daher eher.
kai

[Andy Fuchs]

On 26.04.10 21:11, "Kai 'wusel' Siering" <wus...@googlemail.com> wrote:

>> Ich war in meiner Frage nicht praezise genug. Verwenden wir time, also
>> die Anzahl der Sekunden seit 01.01.1970 00:00:00 UTC in Unix bzw. 1904
>> in MacOS? Damit waere dann auch gleich die Frage nach der Zeitzone
>> beantwortet.
>
> Wieso ist damit die Frage nach der Zeitzone beantwortet?

UTC == eindeutig

> Unix' time_t läuft IIRC im Frühjar 2038 über, latent verbietet sichdessen
> Nutzung für neue Anwendungen daher eher.

Nunja.. ich gehe mal davon aus, dass es bis 2038 noch die ein oder andere
Perl/Unix/dingsda - Revision geben wird und selbst time_t bis dorthin
64-bittig ist. Also würde ich davon JETZT keine Entscheidung abhängig
machen.

a.

[Dr. Boris Neubert]

Hallo,

Kai 'wusel' Siering schrieb:

>> - E7 Vorschlaege fuer das Format der maschinenlesbaren Zeit gesucht.
>
> Irgendwas, womit man einfach rechnen kann (time_t, also Sekunden seit X,
> wäre cool, aber die Unix-Variante ist IIRC nur 32bittig und rotiert in
> 2038 auf 0), möglichst ohne groß Umrechnungsroutinen zu nutzen (Negativ-
> beispiel ist dieses TAI64 oder so, was qmail in Logs nutzt ... Genau wie
> 'ne Atomuhr und mindestens so handlich ...).

Dein Einwand zum Jahr-2038-Problem ist valide und betrifft 32bittige
aber nicht 64bittige Systeme.

Am Ende des Tages muessen wir alle Vor- und Nachteile gegeneinander
abwaegen. Fuer time spricht u.a., dass es ausserordentlich bequem ist,
diese Funktion zu nutzen und dass time selbst zeitzonenfrei ist
(idealisiert: time liefert ueberall auf der Welt zum selben Zeitpunkt
dasselbe Ergebnis) und perl Methoden bereitstellt, time in die Uhrzeit
der lokalen Zeitzone zu uebersetzen.

Arbeitet jemand unter MacOS und kann bestaetigen, dass dort perl in time
die Anzahl der Sekunden seit 01.01.1904 00:00:00 UTC statt der
Unix-Epoche 01.01.1970 00:00:00 UTC zurueckliefert. Dann haetten wir
naemlich ein Portabilitaetsproblem.

Gruesse,
Boris

[Rudolf Koenig]

> Dein Einwand zum Jahr-2038-Problem ist valide und betrifft 32bittige
> aber nicht 64bittige Systeme.

Wuerde ich nicht so allgemein sagen, schliesslich ist ja noch ein perl
zwischen OS und fhem.pl. Und angeblich ist genau das 2038-er Problem mit
perl 5.12 geschichte (ungeprueft).

> Dann haetten wir naemlich ein Portabilitaetsproblem.

Haben wir, siehe auch perldoc -f time. Ob das jetzt ein K.O. ist, sei
hingestellt.

[Dr. Boris Neubert]

Hallo,

(Zeichensatz fuer Readings u.ae.)

Andy Fuchs schrieb:

> UTF-8

an sich ist Unicode aufgrund der Abdeckung (Grad, m^2, m^3) mein
Favorit. Allerdings handeln wir uns damit eine Reihe von Problemen ein:
- Jedes Programmiers Editor muss den Quellcode in Unicode speichern und
jeder Programmierer muss sich darum kuemmern, das auch zu tun. Keine
Ahnung was passiert, wenn mal zwischendurch latin1 eingecheckt wird oder
eine andere Kodierung.
- Keine Ahnung, welche Kodierungsumwandlungen auf dem Weg von der
Programmdatei ueber perl ueber den Webservice oder telnet die Zeichen
verhunzen.
- Jedes Frontend muss in der Lage sein, Unicode in UTF-8 zu erkennen und
korrekt darzustellen.

Die Einschraenkungen, die sich aus der Verwendung von ASCII ergeben,
sind m.E. nicht so gravierend, wie diese potentiellen Probleme.

Rudi, Du hattest fuer ASCII plaediert. Welche Argumente hast Du dafuer?

Gruesse,
Boris

[Kai 'wusel' Siering]

Andy Fuchs wrote:
> On 26.04.10 21:11, "Kai 'wusel' Siering" <wus...@googlemail.com> wrote:
>
>>> Ich war in meiner Frage nicht praezise genug. Verwenden wir time, also
>>> die Anzahl der Sekunden seit 01.01.1970 00:00:00 UTC in Unix bzw. 1904

Das UTC habe ich übersehen, sorry, ist 'n bißchen her, daß ich mit time()
was gemacht habe ;)

Allerdings ist der Wert mehr so unbrauchbar, nicht nur wegen des "Jahr 2038-
Problems":

| POSIX.1 defines seconds since the Epoch as a value to be interpreted as
| the number of seconds between a specified time and the Epoch, according
| to a formula for conversion from UTC equivalent to conversion on the naive
| basis that leap seconds are ignored and all years divisible by 4 are leap
| years. This value is not the same as the actual number of seconds between
| the time and the Epoch, because of leap seconds and because clocks are not
| required to be synchronised to a standard reference. The intention is that
| the interpretation of seconds since the Epoch values be consistent; see
| POSIX.1 Annex B 2.2.2 for further rationale.

>> Unix' time_t läuft IIRC im Frühjar 2038 über, latent verbietet sichdessen
>> Nutzung für neue Anwendungen daher eher.
>
> Nunja.. ich gehe mal davon aus, dass es bis 2038 noch die ein oder andere
> Perl/Unix/dingsda - Revision geben wird und selbst time_t bis dorthin
> 64-bittig ist.

Also, meine embedded-Kisten sind definitiv nicht 64bittig, und bis vor einem
Jahr lief noch ein Amiga 4000 Tower (Motorola 68040, 25 MHz, 16 MB RAM) als
Nameserver für meine Domains (Linux 2.0.36, nativer Build dauerte eine Nacht
vor rd. 10 Jahren ...). Rechne ich das für meinen SheevaPlug hoch, rennt der
2020 noch mit FHEM (sofern das neue Netzteil länger als die 6 Monate des letzten
hält ...), sind dann zwar noch immer 18 Jahre ;), aber ganz so locker würde
ich das nicht sehen.

> Also würde ich davon JETZT keine Entscheidung abhängig
> machen.

Wann dann? 2011, 2015, 2027 oder erst 2042?
kai

[Kai 'wusel' Siering]

Dr. Boris Neubert wrote:

> an sich ist Unicode aufgrund der Abdeckung (Grad, m^2, m^3) mein
> Favorit. Allerdings handeln wir uns damit eine Reihe von Problemen ein:
> - Jedes Programmiers Editor muss den Quellcode in Unicode speichern und
> jeder Programmierer muss sich darum kuemmern, das auch zu tun. Keine
> Ahnung was passiert, wenn mal zwischendurch latin1 eingecheckt wird oder
> eine andere Kodierung.

Oh, das gibt Stunden voll Spaß, bei UTF-8-° als 8859-1 gespeichert kam
glaube ich ° plus ein Steuerzeichen dabei raus:

wusel@greebo:~$ echo -n "°" | iconv -f utf-8 -t utf-8 | xxd
0000000: c2b0 ..
wusel@greebo:~$ echo -n "°" | iconv -f utf-8 -t iso-8859-1 | xxd
0000000: b0 .
wusel@greebo:~$ echo -n "°" | iconv -f utf-8 -t WINDOWS-1252 | xxd
0000000: b0 .
wusel@greebo:~$ echo -n "°" | iconv -f utf-8 -t UTF-7 | xxd
0000000: 2b41 4c41 2d +ALA-
wusel@greebo:~$ echo -n "°" | iconv -f utf-8 -t 850 | xxd
0000000: f8 .

(Was immer UTF-7 sein mag, so firm bin ich da dann doch nicht ;) Sieht
aber ungesund aus ;))

> - Keine Ahnung, welche Kodierungsumwandlungen auf dem Weg von der
> Programmdatei ueber perl ueber den Webservice oder telnet die Zeichen
> verhunzen.

Nicht zu vergessen: wenn FHEM UTF-8 ausgibt, das Terminal für Telnet
aber noch mit iso-8859-1 rennt, gibt das ebenfalls "interessante Effekte";
auch von Windows aus könnte das lustig werden, dunno.

> - Jedes Frontend muss in der Lage sein, Unicode in UTF-8 zu erkennen und
> korrekt darzustellen.
>
> Die Einschraenkungen, die sich aus der Verwendung von ASCII ergeben,
> sind m.E. nicht so gravierend, wie diese potentiellen Probleme.

Ack. Zumal eigentlich FHEM gar kein ° ausgeben muß, wenn die Einheiten
extern definiert werden und nicht in den gelieferten Werten ausgabefer-
tig aufbereitet.

Kurzum, ich tendiere mehr denn je dafür, da ich keinen Vorteil in UTF-8
sehe, hingegen aber manigfaltige potenzielle Probleme, auf 7-Bit US-ASCII
sich zu beschränken.
kai

[Andy Fuchs]

On 27.04.10 19:14, "Kai 'wusel' Siering" <wus...@googlemail.com> wrote:

> Also, meine embedded-Kisten sind definitiv nicht 64bittig, und bis vor einem
> Jahr lief noch ein Amiga 4000 Tower (Motorola 68040, 25 MHz, 16 MB RAM) als
> Nameserver für meine Domains (Linux 2.0.36, nativer Build dauerte eine Nacht
> vor rd. 10 Jahren ...). Rechne ich das für meinen SheevaPlug hoch, rennt der
> 2020 noch mit FHEM (sofern das neue Netzteil länger als die 6 Monate des
> letzten
> hält ...), sind dann zwar noch immer 18 Jahre ;), aber ganz so locker würde
> ich das nicht sehen.

Nunja... vor 28 Jahren hatte ich gerade mal einen C64 mit 64kB Speicher
(bzw. 32kB verfügbaren Speicher) und einen HP CX Taschenrechner. Wenn ich
das mit meinem jetzigen Maschinenpark vergleiche, kann ich mir schon
vorstellen, dass das 2038 anders aussieht :-)

>> Also würde ich davon JETZT keine Entscheidung abhängig
>> machen.
>
> Wann dann? 2011, 2015, 2027 oder erst 2042?

So gegen 2025 ;-) - dann sieht man auch besser wieviele Kisten noch mit
32bit rennen, oder ob in deren Kernel vielleicht ein 64bit Emulator
eingebaut wurde :-)

a.

[Andy Fuchs]

Hallo Ihrs,

ok - ich verstehe Dein Argument und muss zugeben, dass bei den Readings
vermutlich tatsächlich UTF-8 etwas überzogen ist.

Grundsätzlich fände ich das natürlich (vor allem in den Logs) schön, aber
Deine Argumentation ist absolut valide, so dass ich kein Problem damit hab'
jetzt für was anderes zu stimmen :-)

a.

[Rudolf Koenig]

> Rudi, Du hattest fuer ASCII plaediert. Welche Argumente hast Du dafuer?

Ich bin halt ein ASCII fan (wie man es an meinen Umlauten auch sieht :),
insbesondere wenn es um Quellcode geht. Ich habe in meinem Laufbahn etliche
Probleme mit UTF-8, insb. im/mit Perl gehabt, obwohl das mit den neueren
Versionen besser geworden ist.

Wenn (irgendwannmal) Mehrsprachigkeit gewuenscht wird, dann sollten wir das in
externen, UTF-8 Dateien realisieren, der Quellcode hat ASCII zu bleiben. Die
Leute sollen nicht auf fremdlaendische Kommentare verfallen, schliesslich will
ja auch keiner von mir ungarische Erklaerungen sehen, oder?

[Andy Fuchs]

On 27.04.10 19:58, "Rudolf Koenig" <inf...@koeniglich.de> wrote:

>> Rudi, Du hattest fuer ASCII plaediert. Welche Argumente hast Du dafuer?
>
> Ich bin halt ein ASCII fan (wie man es an meinen Umlauten auch sieht :),
> insbesondere wenn es um Quellcode geht. Ich habe in meinem Laufbahn etliche
> Probleme mit UTF-8, insb. im/mit Perl gehabt, obwohl das mit den neueren
> Versionen besser geworden ist.
>
> Wenn (irgendwannmal) Mehrsprachigkeit gewuenscht wird, dann sollten wir das in
> externen, UTF-8 Dateien realisieren, der Quellcode hat ASCII zu bleiben. Die
> Leute sollen nicht auf fremdlaendische Kommentare verfallen, schliesslich will
> ja auch keiner von mir ungarische Erklaerungen sehen, oder?

Nem beszélek magyarul

:-)

a.

[Dr. Boris Neubert]

Am 27.04.2010 18:37, schrieb Rudolf Koenig:
>> Dein Einwand zum Jahr-2038-Problem ist valide und betrifft 32bittige
>> aber nicht 64bittige Systeme.
>
> Wuerde ich nicht so allgemein sagen, schliesslich ist ja noch ein perl
> zwischen OS und fhem.pl. Und angeblich ist genau das 2038-er Problem mit
> perl 5.12 geschichte (ungeprueft).

siehe http://www.activestate.com/activeperl/features/
=> ActicePerl 5.12.0 ist y2038-konform

Für Perl 5.12 i.a. siehe
http://search.cpan.org/~jesse/perl-5.12.0/pod/perl5120delta.pod#Y2038_compliance

Thema dürfte damit hoffentlich gegessen sein.

>> Dann haetten wir naemlich ein Portabilitaetsproblem.
>
> Haben wir, siehe auch perldoc -f time. Ob das jetzt ein K.O. ist, sei
> hingestellt.

Vorschlag: wrapper fuer time mit

sub TimeNow() {
if($^O =~ m/Mac/) {
return time+2081376000;
} else {
return time;
}
}

Gruesse,
Boris

[Dr. Boris Neubert]

Hallo,

weil ich jetzt fuer ein paar Tage nicht dabei sein kann, habe ich die
Entscheidungsvorlagen fuer die Themen, die wohl weitestgehend ausgegoren
sind, schon mal eingeDOODLEt:


E5a:

Zeitdarstellungen in $defs{DeviceName}{readings}{theReading}{time}

* menschenlesbar
* maschinenlesbar
* sowohl als auch (neben time ein weiterer Eintrag im Hash)

E5b:

Wenn Wahl "maschinenlesbar", dann _alle_ Zeitangaben intern in in diesem
Format


E8:

Readings enthalten grundsaetzlich genau einen Wert ohne Einheit.

E10:

Nach aussen sichtbare Werte in Zeichenkodierung

* ASCII (Codes 32..127)
* UTF-8
* etwas anderem (bitte kommentieren)


Die Abstimmung laeuft bis 03.05.2010 12:00. Eine Alternative gilt als
angenommen, wenn es mehr Ja- als Nein-Stimmen gibt.

Gruesse,

[Rudolf Koenig]

> sub TimeNow() {
> if($^O =~ m/Mac/) {
> return time+2081376000;
> } else {
> return time;
> }
> }

Da bin ich noch nicht sicher.
Ich will immer noch zwischen interne (readings) und externe (FileLog, list)
Representation unterscheiden. Wenn intern Sekunden als Zahl verwendet werden,
dann gibt es keine Notwendigkeit, diese "portabel" zu halten. Und schliesslich
haben die Perl Leute bestimmt was dabei gedacht, wenn time auf dem Mac anders
ist also sonst.

[Kai 'wusel' Siering]

Moin,

Rudolf Koenig wrote:

>> sub TimeNow() {
>> if($^O =~ m/Mac/) {
>> return time+2081376000;
>> } else {
>> return time;
>> }
>> }
>
>
> Da bin ich noch nicht sicher.
> Ich will immer noch zwischen interne (readings) und externe (FileLog, list)
> Representation unterscheiden.

Warum sind >1 Zeitzählung Deiner Ansicht nach sinnvoll?

> Wenn intern Sekunden als Zahl verwendet werden,
> dann gibt es keine Notwendigkeit, diese "portabel" zu halten.

Vorsichtiges ACK.

> Und schliesslich
> haben die Perl Leute bestimmt was dabei gedacht, wenn time auf dem Mac anders
> ist also sonst.

Gedacht haben sie imho da nur eines: wir liefern das, was das OS unten drunter
liefert. Und zumindest lt. cpan sollte die MacOS-Epoche mit den letzten MacOS-
Dinosauriern aussterben:

"Mac OS X is a Unix system, and uses the Unix epoch (1970-01-01T00:00:00). Use DateTime::Format::Epoch::Unix instead."

Siehe auch http://en.wikipedia.org/wiki/Epoch_%28reference_date%29#Notable_epoch_dates_in_computing

Für Zeitdifferenzen im Kleinen ist die Epoch-basierte Sekundenzählung IMHO ok;
da wir aber grade auch Schaltjahre und so korrekt verarbeiten können wollen,
wäre es blöd, den gleichen Fehler, den Sony in der PS3, die am 01.03.2010 massen-
haft den Dienst verweigerte (weil der 29.02.2010 errechnet wurde), gemacht hat,
in FHEM 5 zu wiederholen.
kai

[Rudolf Koenig]

> Warum sind >1 Zeitzählung Deiner Ansicht nach sinnvoll?

Ich frag mich auch, aber es gibt hier wohl Leute, die unbedingt auf einen fuer
mich nicht-lesbaren-Zahl (nlZ) bestehen, aus fuer mich _relativ_ unwichtigen
Gruenden:

- Zeitdifferenze rechnen
(man kann statt a-b immer noch time_diff(a,b) haben)
- Doppelte Speicherung einmail um 2:00 im Herbst, beim Zeitwechsel.

Falls man auf die sog. >1 Zeitzaehlung verzichtet, dann muss ich immer
ein Prograemmchen aufrufen, wenn ich feststellen will, wann was passierte.
Das finde ich jetzt schon extrem nerwig in CUL, der fuer boottime ein Hex-Zahl
ausspuckt, aber das hat 200 Byte notwendigen Programm-Speicher gerettet, und
damit zwei unterschiedliche Firmwares erspart, und damit ein fuer mich
greifbares Problem geloest.

Ich will wenigstens da, wo der Benutzer die Zeitstempel sieht/sehen kann
lesbare Datumsfelder haben.

> Gedacht haben sie imho da nur eines: wir liefern das, was das OS unten drunter
> liefert. Und zumindest lt. cpan sollte die MacOS-Epoche mit den letzten MacOS-
> Dinosauriern aussterben:

Dieser Fall ist mir zu hypothetisch (jemand wechselt von einem MacOS basierten
fhem auf Unix/Windows, und will seinen alten Konfig portieren), das Problem
kann gerne beim Wechsler bleiben, da schreibe ich lieber ein FAQ/HOWTO.

Und: mit der "alten" Darstellung waere das nicht passiert :)

[Kai 'wusel' Siering]

Hi,

Rudolf Koenig wrote:

>> Warum sind >1 Zeitzählung Deiner Ansicht nach sinnvoll?
>
> Ich frag mich auch, aber es gibt hier wohl Leute, die unbedingt auf einen fuer
> mich nicht-lesbaren-Zahl (nlZ) bestehen, aus fuer mich _relativ_ unwichtigen
> Gruenden:
>
> - Zeitdifferenze rechnen
> (man kann statt a-b immer noch time_diff(a,b) haben)
> - Doppelte Speicherung einmail um 2:00 im Herbst, beim Zeitwechsel.

DST-Handling hat mit der Zeitrepräsentation erst einmal wenig zu tun, oder?

Ich für meinen Teil kann nur sagen, daß ich nicht groß nachgeschaut habe,
ob es in Perl oder FHEM Unterstützung gibt für die Zeitdifferenzberechnung
basierend auf FHEM-Zeitwerten, daher habe ich einfach die Krücke über time()
gewählt:

if(defined($defs{$self}{PREV}{TIMESTAMP})) {
if($defs{$self}{PREV}{TIMESTAMP} > time()-5) {
if(defined($defs{$self}{PREV}{STATE})) {
if($defs{$self}{PREV}{STATE} eq $state) {
Log GetLogLevel($def->{NAME},5), sprintf("FHTTK skipping state $state as last similar telegram was received less than 5 (%d) secs ago", $defs{$self}{PREV}{STATE}, time()-$defs{$self}{PREV}{TIMESTAMP});
return "";
}
}
}
}

$defs{$self}{READINGS}{$reading}{TIME} zu parsen, dazu hatte ich nun wirk-
lich keine Lust, mit all den Ausnahmen, die man bei Sekunden, Minuten, Stunden
und Wochentagen, Monatsnummern und Jahren letztlich berücksichtigen muß.

(Vielleicht ist die Abstimmung darüber doch zu voreilig?)

Initial ging ich von [local]time() statt TimeNow() aus, weil TimeNow() genau
keinen Mehrwert für die interne Repräsentation bringt:

sub
TimeNow()
{
my @t = localtime;
return sprintf("%04d-%02d-%02d %02d:%02d:%02d",
$t[5]+1900, $t[4]+1, $t[3], $t[2], $t[1], $t[0]);
}

Anstatt also den Sekundenwert umständlich in Jahre, Monate, Monatstage,
Stunden, Minuten und Sekunden zu wandeln und diesen menschlichen Irrsinn
bei jeder Berechnung zwei(!)mal zu wiederholen (TimeNow()-Wert in Sekun-
den, Berechnen, Wert wieder ins TimeNow()-Format wandeln (durch FmtDate-
Time(), korrekt?)), wollte ich nur das Maschinendatum gespeichert wissen,
was "nur" bei jeder "Ausgabe in Richtung Mensch" ein FmtDateTime($var)
benötigen würde. KISS; Formatwandlung nur da, wo notwendig.

Soweit dazu. Daß time(), anders als gmtime()/localtime() aber Schalt-
zeiten nicht berücksichtigt, habe ich ehrlich gesagt verdrängt -- in-
sofern werde ich u. a. meinen bestehenden Code natürlich anpassen --;
da Date::Parse das Y2k38-Thema auch nicht löst ...

LIMITATION

Date::Parse uses Time::Local internally, so is limited to only parsing dates which result in valid values for Time::Local::timelocal. This generally means dates between 1901-12-17 00:00:00 GMT and 2038-01-16 23:59:59 GMT

... frage ich mich, im Frühjahr 2010, ob die Diskussion über Y2k38 nun
wichtig oder müßig ist; ich hatte eigentlich erwartet/gehofft, daß Perl
das Thema adressieren würde :(


Zu UTC vs. lokaler Zeit:

Wie schon einmal gesagt, für mich stellt sich das Zeitumstellungsproblem
nicht, da ich ggf. statt 02:00 eben 01:59 oder 03:01 wählen würde, sollte
ein Ausfall bzw. ein mehrmaliges Ausführen in einer Nacht für mich ein Thema
sein. Da ich als Mensch es nicht gewohnt bin, mein Zeitzonen zu arbeiten,
würde ich dazu tendieren, jede Zeitwert vom Benutzer als in der lokalen Zeit-
zone befindlich zu interpretieren. In dem Fall kann UTC UTC bleiben und die
Speicherung in lokaler Zeit erfolgen ...


Was spräche denn gegen ISO 8601 als Zeitformat i. V. m. "use Date::Parse;"?
Das hätte den Vorteil, daß die "maschinenlesbare" Zeitrepräsentation auch
noch "menschenlesbar" ist, dieses "maschinenlesbare" Format plattformüber-
greifend "as-is" gespeichert werden kann und über Date::Parse Wandlungs-
routinen bereit stehen, um auch Zeitidfferenzen berechnen zu können.

http://www.iso.org/iso/date_and_time_format

> * Date and time represents a specified time of a specified day. When use is made of the calendar date the representation is:
>
> YYYY-MM-DDThh:mm:ss
>
> where the capital letter T is used to separate the date and time components. Thus, for a very precise date and time, look at this:
>
> Example: 2003-04-01T13:01:02 represents one minute and two seconds after one o'clock in the afternoon of 2003-04-01.

Gut, wahrscheinlich kann man "str2time(TimeNow());" machen, was aber immer
noch "use Date::Parse;" voraussetzte. Da auch perlport ISO 8601 vorschlägt
(wenngleich in meiner Version zumindest /falsch ausgeführt/), sollte man das
IMHO beherzigen:

Time and Date
[...]
Don’t assume that the epoch starts at 00:00:00, January 1, 1970,
because that is OS- and implementation-specific. It is better to store
a date in an unambiguous representation. The ISO 8601 standard defines
YYYY-MM-DD as the date format, or YYYY-MM-DDTHH-MM-SS (that’s a literal
"T" separating the date from the time). [...]


(EPOCH)

>> Gedacht haben sie imho da nur eines: wir liefern das, was das OS unten drunter
>> liefert. Und zumindest lt. cpan sollte die MacOS-Epoche mit den letzten MacOS-
>> Dinosauriern aussterben:
>
> Dieser Fall ist mir zu hypothetisch (jemand wechselt von einem MacOS basierten
> fhem auf Unix/Windows, und will seinen alten Konfig portieren), das Problem
> kann gerne beim Wechsler bleiben, da schreibe ich lieber ein FAQ/HOWTO.

Hmm? Nutzt noch irgendwer MacOS (nicht(!) MacOS X)? Und was hat eine maschinen-
lesbare Zeitrepräsentation mit dem Konfigfile zu tun? Niemand wollte, daß in der
Konfiguration nun mit Sekunden seit der Epoche gearbeitet wird,

define at_EndOfDays at 1272442532 set WeltuntergangsLED on

wäre etwas zu viel verlangt -- und ein Rückschritt auf mehreren Ebenen ;)

Du vermischt hier was. Aber ISO 8601 als internes Zeitformat i. V. m.
"use Date::Parse;" löst eigentlich alle diese Themen, oder? ;)
kai

[Andy Fuchs]

On 28.04.10 10:24, "Kai 'wusel' Siering" <wus...@googlemail.com> wrote:

>
> Was spräche denn gegen ISO 8601 als Zeitformat i. V. m. "use Date::Parse;"?
> Das hätte den Vorteil, daß die "maschinenlesbare" Zeitrepräsentation auch
> noch "menschenlesbar" ist, dieses "maschinenlesbare" Format plattformüber-
> greifend "as-is" gespeichert werden kann und über Date::Parse Wandlungs-
> routinen bereit stehen, um auch Zeitidfferenzen berechnen zu können.

Das hatte ich auch schon mal vorgeschlagen. Es ist zwar - nach wie vor -
eine Krücke, aber mit der könnte man leben, zumal es auch in anderen
Sprachen (PHP, JavaScript, etc...) Parser, bzw. Klassen gibt mit dem man
ISO-Date-Berechnungen einfach ausführen kann.

> Da ich als Mensch es nicht gewohnt bin, mein Zeitzonen zu arbeiten,
> würde ich dazu tendieren, jede Zeitwert vom Benutzer als in der lokalen Zeit-
> zone befindlich zu interpretieren. In dem Fall kann UTC UTC bleiben und die
> Speicherung in lokaler Zeit erfolgen ...

UTC hat allerdings viele Vorteile, gerade in Punkto 'Fernsteuerung', wo
meines erachtens, das Wortfragment 'fern' quasi UTC bereits impliziert.
Zieht man UTC stringent durch das ganze System durch, sind Zeitberechnungen
(oder Abfragen) ein Klacks - egal, wo man sich befindet, und egal wo fhem
läuft (sogar Zeitzonen übergreifend).

a

[Rudolf Koenig]

> >- Doppelte Speicherung einmail um 2:00 im Herbst, beim Zeitwechsel.
>
> DST-Handling hat mit der Zeitrepräsentation erst einmal wenig zu tun, oder?

Doch:
"2010-10-31 02:30" gibt es zweimal, fallst man UTC Sekunden verwendet, dann
ist das kein Problem.

> Ich für meinen Teil kann nur sagen, daß ich nicht groß nachgeschaut habe,
> ob es in Perl oder FHEM Unterstützung gibt für die Zeitdifferenzberechnung
> basierend auf FHEM-Zeitwerten,

Siehe auch 99_Utils/time_str2num (verwendet mktime).

Koennten wir leicht mit weiteren Funktionen ergaenzen. Ich habe auch nichts
dagegen, das manche Module, die mit Zeiten rechnen wollen ihre Timestamps in
UTC abspeichern. Ich will nur als "Benutzer" die wichtigsten Daten lesen
koennen, auch in den Dateien, die ich mit einem Editor oeffnen kann.

> Was spräche denn gegen ISO 8601 als Zeitformat i. V. m. "use Date::Parse;"?

Dass mit mktime()/time_str2num das Problem jetzt schon erledigt ist, und
ich immer Angst habe, wenn Date::xxx Module installiert werden muessen. Die
tendieren dazu, ganz beilaeufig 1000 andere Module mitzuinstallieren, siehe
Sunrise & co. Viele haben sogar Probleme, Device::Serial zu installieren.

> Hmm? Nutzt noch irgendwer MacOS (nicht(!) MacOS X)?

Danke fuer den Hinweis! Habs gerade geprueft, perl @ OS-X liefert Sekunden
seit 1970 -> MacOS-ohne-X ist mir (sehr sehr :) egal...

> define at_EndOfDays at 1272442532 set WeltuntergangsLED on
> wäre etwas zu viel verlangt -- und ein Rückschritt auf mehreren Ebenen ;)

Ja, vor so einem Weltuntergang habe ich auch Angst.
Btw. zu welcher Weltuntergang-Glaubensrichtung gehoerst Du denn? :)

> Zieht man UTC stringent durch das ganze System durch, sind Zeitberechnungen
> (oder Abfragen) ein Klacks - egal, wo man sich befindet, und egal wo fhem
> läuft (sogar Zeitzonen übergreifend).

Ob das fuer fhem so relevant ist... Ich will fhem nicht fuer alle Situationen
perfekt machen, das endet in sowas wie SAP. Macht zwar alles theoretisch
perfekt, aber es ist ein Moloch, und damit fuer vieles uninteressant.

[Dr. Boris Neubert]

Hallo,

hier die Ergebnisse der Abstimmung:

E5a: Zeitdarstellung
nur menschenlesbar: 1:3
nur maschinenlesbar: 3:1
beides: 0:4
E5b: ALLE Zeitangaben im Programm maschinenlesbar: 3:1
E8: Readings enthalten genau einen Wert ohne Einheit: 4:0
E10: Zeichenkodierung
ASCII: 4:0
UTF-8: 0:4
andere: 0:4

Die Ergebnisse werden unter
http://fhemwiki.de/index.php/DevelopmentGuidelines dokumentiert.

Grüße,

[Dr. Boris Neubert]

Am 28.04.2010 08:56, schrieb Rudolf Koenig:
> Gruenden:
>
> - Zeitdifferenze rechnen
> (man kann statt a-b immer noch time_diff(a,b) haben)
> - Doppelte Speicherung einmail um 2:00 im Herbst, beim Zeitwechsel.

den zweiten Punkt verstehe ich nicht. Die Sekunden seit der Unix-Epoche
sind eine homogene und universell eindeutige Zeitdarstellung, während es
die Angabe von Tag, Monat, Jahr, Stunde, Minute, Sekunde nur mit Angabe
von Zeitzone incl. DST-Flag ist.

> Ich will wenigstens da, wo der Benutzer die Zeitstempel sieht/sehen kann
> lesbare Datumsfelder haben.

Wo entstehen denn eigentlichen Lücken zum Zustand in fhem 4.x und welche
davon können nur mit relativ hohem Aufwand geschlossen werden?

1. Frontends

GUIs: Werden auf Zeitzone und Format konfiguriert und transformieren
Maschinenzeit in menschenfreundliche Lokalzeit (ggf. wahlweise in die
Zeit auf der Kuckucksuhr des Betrachters des GUI oder auf der
Kuckucksuhr, die über dem fhem-Server hängt).

list: mit attr global timezone CEST und attr global timeformat
"YYYY-MM-DD hh:mm:ss" liefert list menschenlesbare Zeiten

xmllist: "xmllist" liefert Maschinenzeit, "xmllist friendly" analog zu
list wieder menschenlesbare Zeiten (wozu?)

Mit sinnvollen Defaults, die vom Betriebssystem ausgelesen werden, ist
dann auch der Konfigurationsaufwand null.

2. Logs

Hier steht sowieso noch die Diskussion an, wie Logs künftig gefüttert
werden. Ich hätte da auch gerne sowohl eine menschenlesbare als auch
eine von einer Maschine sehr leicht auslesbare Variante. Vielleicht
genügt es ja schon, ein Format beim FileLog anzugeben. Aber bitte das
Faß Logs erst später aufmachen, bevor wir uns in diesem Thread verzetteln.

3. save-File

Braucht man dort menschenlesbare Einträge?


Fehlt noch was?

Grüße,
Boris

[Rudolf Koenig]

> > - Zeitdifferenze rechnen
> > (man kann statt a-b immer noch time_diff(a,b) haben)
> > - Doppelte Speicherung einmail um 2:00 im Herbst, beim Zeitwechsel.
>
> den zweiten Punkt verstehe ich nicht. Die Sekunden seit der Unix-Epoche
> sind eine homogene und universell eindeutige Zeitdarstellung, während es
> die Angabe von Tag, Monat, Jahr, Stunde, Minute, Sekunde nur mit Angabe
> von Zeitzone incl. DST-Flag ist.

mit fhem <= 4.9 wird 2010.10.31_02:30 zweimal in jedem Logfile stehen, und
schaut etwas ungewoehnt aus in den fhem plots.

> Wo entstehen denn eigentlichen Lücken zum Zustand in fhem 4.x und welche
> davon können nur mit relativ hohem Aufwand geschlossen werden?

Ich arbeite daran, dass keine Luecken entstehen :), ich will weiterhin, dass im
log wie bisher

2010.05.04 21:25:28.429 2: FS20 Fenster1 on

steht, und nicht (oder nur optional)

1273001128.429 2: FS20 Fenster1 on

> list: mit attr global timezone CEST und attr global timeformat
> "YYYY-MM-DD hh:mm:ss" liefert list menschenlesbare Zeiten

Wenn, dann sollte unlesbar eine Option sein (list -unreadable :), sowohl fuer
list, als auch fuer xmllist. Als Nebeneffekt muss nicht jeder sofort alles
anpassen.

> Mit sinnvollen Defaults, die vom Betriebssystem ausgelesen werden, ist
> dann auch der Konfigurationsaufwand null.

??? Verstehe ich nicht.

> 3. save-File
>
> Braucht man dort menschenlesbare Einträge?

Ich schon, andere vielleicht auch :) Ich brauche prinzipiell in jedem Datei
lesbare Eintraege. Beispiel: z.Zt habe ich haeufig das Problem, das die S300-er
einmal am Tag kaputte Daten liefern. Bis das gefixed ist kann ich die logfile
per "vi" in Ordnung bringen. Diesen Feature will ich (werde ich :) nicht
missen.

[Kai 'wusel' Siering]

Hmm, übersehen bislang, sorry.

Dr. Boris Neubert wrote:

>>> Dein Einwand zum Jahr-2038-Problem ist valide und betrifft 32bittige
>>> aber nicht 64bittige Systeme.
>> Wuerde ich nicht so allgemein sagen, schliesslich ist ja noch ein perl
>> zwischen OS und fhem.pl. Und angeblich ist genau das 2038-er Problem mit
>> perl 5.12 geschichte (ungeprueft).
>
> siehe http://www.activestate.com/activeperl/features/
> => ActicePerl 5.12.0 ist y2038-konform
>
> Für Perl 5.12 i.a. siehe
> http://search.cpan.org/~jesse/perl-5.12.0/pod/perl5120delta.pod#Y2038_compliance
>
> Thema dürfte damit hoffentlich gegessen sein.

Dazu erst einmal dies:

This is perl, v5.10.0 built for i486-linux-gnu-thread-multi (Ubuntu 9.10)
This is perl, v5.10.0 built for arm-linux-gnueabi-thread-multi (Ubuntu 9.04)

Lies: nur, wenn Perl 5.12 als Voraussetzung für FHEM 5 definiert wird,
ist »das Thema gegessen«. Frage für mich: rechtfertigt diese -- imho vage --
Aussage zu Y2038 ggf. das Außenvorlassen z. B. von älteren Perl-Implemen-
tationen auf Fritzboxen, WRTs und anderen uClibc-Kistchen? Und bringen
"perl's core time-related functions" Funktionen zur Zeitdifferenzberechnung
mit oder kann sich ein Problem durch die Hintertür einschleichen in eigenen
Routinen?
kai

[Kai 'wusel' Siering]

Rudolf Koenig wrote:

>> Was spräche denn gegen ISO 8601 als Zeitformat i. V. m. "use Date::Parse;"?
>
> Dass mit mktime()/time_str2num das Problem jetzt schon erledigt ist, und
> ich immer Angst habe, wenn Date::xxx Module installiert werden muessen. Die
> tendieren dazu, ganz beilaeufig 1000 andere Module mitzuinstallieren, siehe
> Sunrise & co. Viele haben sogar Probleme, Device::Serial zu installieren.

Tja, da sind sie wieder, die alten Themen ;) Ein perl-Executable auf einer
Plattform bringt eben noch kein "perl" auf diese, mindestens der Rattenschwanz
an Unterstützung für die Installation beliebiger CPAN-Module gehört dazu (und
fehlt bei embedded leider oft).

Aber wo fangen "wir" mit der Wiedererfindung des Rades an und wo hören wir auf?
Device::Serial ist offensichtlich ein Muß; Zeitberechnung machen wir lieber selbst?

(Ja, auch das ist letztlich ein "Quo vadis"- und ein Kompatibilitätsthema für V5.)

>> define at_EndOfDays at 1272442532 set WeltuntergangsLED on
>> wäre etwas zu viel verlangt -- und ein Rückschritt auf mehreren Ebenen ;)
>
> Ja, vor so einem Weltuntergang habe ich auch Angst.
> Btw. zu welcher Weltuntergang-Glaubensrichtung gehoerst Du denn? :)

Ich bin mir ziemlich sicher, daß der Weltuntergang nicht mehr in meiner Restlebens-
zeit stattfindet ;)

>> Zieht man UTC stringent durch das ganze System durch, sind Zeitberechnungen
>> (oder Abfragen) ein Klacks - egal, wo man sich befindet, und egal wo fhem
>> läuft (sogar Zeitzonen übergreifend).
>
> Ob das fuer fhem so relevant ist... Ich will fhem nicht fuer alle Situationen
> perfekt machen, das endet in sowas wie SAP. Macht zwar alles theoretisch
> perfekt, aber es ist ein Moloch, und damit fuer vieles uninteressant.

Einerseits dies. Andererseits wird es nur eindeutig, wenn man die Zeitzone immer
mitführt. Wenn mein FHEM in Deutschland zusätzlich einen CUN_ie in Irland schalten
soll -- mal von der relativen Sinnlosigkeit abgesehen ;) --, wie wird das dann
definiert (der CUN im OG im Haus in D heißt CUN_OG), wenn beide um 12:00 lokaler
Zeit schalten sollen? Die Frage ist imho insofern valide, als daß es die Frage auf-
wirft, ob zu einem Gerät eine Zeitzone gehören soll und FHEM jede Zeitangabe dann
auf die jeweilige Ortszeit umrechnet oder, wie bisher, mit einer Zeit gearbeitet
wird, dann muß ich wie bisher "at 12:00 set CUL_OG" und "at 11:00 set CUL_ie" sagen.

Lustig, vielleicht sogar für eine Handvoll FHEM-Nutzer potentiell irgendwann einmal
nützlich, wäre die Möglichkeit, "at 12:00-TZ(Ireland) set CUL_ie" sagen zu können -
aber wäre das nicht sogar schon jetzt möglich, indem man "wirre Perl-Ausdrücke" als
Argument übergibt, die genau dies ausrechen?

Oder verstehe ich grade was grundlegend miß?
kai

[Rudolf Koenig]

> Wenn mein FHEM in Deutschland zusätzlich einen CUN_ie in Irland schalten soll
> -- mal von der relativen Sinnlosigkeit abgesehen ;) --, wie wird das dann

> definiert ...

Weitere Aufgabe: Sowohl in Irland auch "hier" beim Sonnenaufgang die Rolladen
aufmachen.
Und genau darum geht es. Theoretisch ist Dein Einwand korrekt, praktisch finde
ich es irrelevant, und ich will es einfach nicht loesen.

Ich wuerde beide Probleme mit einer FHEM <-> FHEM Kopplung loesen (wollte ich
schon lange schreiben), erfordert natuerlich einen lokalen FHEM in Irland. Und
wieso ausgerechnet Irland? Thailand ist doch viel wichtiger... :)

[Kai 'wusel' Siering]

Rudolf Koenig wrote:

> Weitere Aufgabe: Sowohl in Irland auch "hier" beim Sonnenaufgang die Rolladen
> aufmachen.

Naja, das ist aber schon zwischen Hamburg und München ein Thema in einem FHEM,
oder? ;) (Definition der geografischen Lokation findet statt in 99_SUNRISE_el.pm,
nicht in FHEM.cfg, oder?)

> Und genau darum geht es. Theoretisch ist Dein Einwand korrekt, praktisch finde
> ich es irrelevant, und ich will es einfach nicht loesen.

Zeitzonenübergreifende Nutzung sehe auch ich nicht als Thema; aber mit der
Frage localtime vs. gmtime ergeben sich eben weitere:

1. Welche "Zeitzone" beschreibt fhem.cfg? (IMHO derzeit: local => DST-Thematik)

2. In welcher "Zeitzone" (hier: GMT/UTC vs. local) arbeitet FHEM (relevant
für Unterscheidbarkeit DST->non-DST), derzeit setzt TimeNow() auf localtime.

Ist die Eindeutigkeit von Aktionen während der "doppelten Stunde" beim Rück-
schwenk von DST relevant? Diese Frage sollten wir uns erst mal stellen -- und
beantworten ;)

> Ich wuerde beide Probleme mit einer FHEM <-> FHEM Kopplung loesen (wollte ich
> schon lange schreiben),

Hmmm, ich würde die gar nicht koppeln, reduziert die Komplexität, Abhängig-
keiten und verbessert so schon mathematisch die Verfügbarkeiten ;)

> erfordert natuerlich einen lokalen FHEM in Irland. Und
> wieso ausgerechnet Irland? Thailand ist doch viel wichtiger... :)

Dunno, _da_ war ich noch nicht ;) Und wenn ich auch -- wegen des Wetters --
eher gen Italien ziehen wollen würde, war Irland das erstbeste nicht-MEZ-
Beispiel, das mir einfiel ;)
kai

[Rudolf Koenig]

> Ist die Eindeutigkeit von Aktionen während der "doppelten Stunde" beim Rück-
> schwenk von DST relevant?

Meiner Ansicht nach sind die Nachteile nicht so gravierend wie die Probleme bei
alternativen Zeitspezifikationen, die das Problem vermeiden.

[Dr. Boris Neubert]

Rudolf Koenig schrieb:

> Ich arbeite daran, dass keine Luecken entstehen :), ich will weiterhin, dass im
> log wie bisher
>
> 2010.05.04 21:25:28.429 2: FS20 Fenster1 on
>
> steht, und nicht (oder nur optional)
>
> 1273001128.429 2: FS20 Fenster1 on
>

>> Mit sinnvollen Defaults, die vom Betriebssystem ausgelesen werden, ist
>> dann auch der Konfigurationsaufwand null.
>
> ??? Verstehe ich nicht.

Mein Vorschlag ist, zwei globale Attribute timezone und timeformat
einzufuehren. Beide Attribute werden beim Start von fhem mit
Default-Werten vorbesetzt, die sich z.B. aus den Locale-Einstellungen
ergeben. (Der versierte Anwender kann die Formate dann mit attr global

timezone CEST und attr global timeformat "YYYY-MM-DD hh:mm:ss"

ueberschreiben.)

timezone und timeformat werden dann verwendet fuer list, xmllist mit
Argument friendly und fuer die menschenlesbaren Logs verwendet, so dass
die Defaulteinstellungen Deinen o.g. Anforderungen sowie vermutlich den
von der ueberwiegenden Mehrheit der Anwender genuegen, bei denen fhem
und Frontend in der selben Zeitzone wie der Anwender sind.

Fuer eindeutige Angaben in der save-Datei, die menschen- und
maschinenlesbar zugleich sein sollen, kommt m.E. wegen der Eindeutigkeit
nur ein _nicht_ konfigurierbares Format, z.B. ISO8601 in Frage mit
Angabe der Zeitzone (siehe Wikipedia):

2009-06-30T18:30:00+02:00 = 18:30:00 Uhr am 30. Juni 2009 in Frankfurt
(MESZ - Sommerzeit)

Gruesse,
Boris

[Rudolf Koenig]

> Mein Vorschlag ist, zwei globale Attribute timezone und timeformat
> einzufuehren.

timeformat verstehe ich, timezone nicht. Der versierte (und masochistisch
veranlagte :) fhem user kann jetzt schon setenv TZ UTC machen, und hat dann
keine Probleme bei der Zeitumstellung, bzw interkontinentalen fhem
Synchronization.

> Fuer eindeutige Angaben in der save-Datei, die menschen- und maschinenlesbar
> zugleich sein sollen, kommt m.E. wegen der Eindeutigkeit nur ein _nicht_
> konfigurierbares Format, z.B. ISO8601 in Frage mit Angabe der Zeitzone (siehe
> Wikipedia):

Falls es die langwierige Diskussion ueber diesen (meiner privaten Ansicht nach
sehr theoretischen) Diskussion verkuerzt, koennen wir ISO8601 als Option bei
timeformat einfuehren. Dann muss ich nur fhem.pl, 98_Utils.pm und 98_SVG.pm
modifizieren und testen. Und at (90_at.pm) bleibt so wie es ist.
Und dann sind die Probleme, die bisher laut Google Group niemanden gestoert
haben, endlich weg. :/

[Dr. Boris Neubert]

ich fasse mal zusammen:

Zeitdarstellungen:
A. Gleitkommazahl= Sekunden seit der Unix-Epoche (was time liefert)
(funktioniert mit perl 5.12 auch noch nach 2038 und auf Macs ab MacOS X)
B. ISO8601 mit optionaler Zeitzonenangabe, wobei bei fehlender Zeitzone
die Einstellung des Systems verwendet wird, wo fhem laeuft
C. Benutzerdefiniertes Zeitformat mit optional definierter
Zeitzonenangabe, wobei bei fehlender Zeitzone die Einstellung des
Systems verwendet wird, in dessen Kontext die Ausgabe zum Benutzer erfolgt

Verwendung:
1. Zur Programmlaufzeit in Variablen immer A
2. In Konfigurationsdateien immer B
3. In Logs, die fuer den Menschen bestimmt sind, C
4. In Logs, die fuer die Maschine bestimmt sind, also z.B. bei
Weiterverarbeitung in einem GUI, A
5. In Listen (list, xmllist friendly), die fuer den Menschen bestimmt
sind, C
6. In Listen (xmllist), die fuer die Maschine bestimmt sind, also z.B.
bei Weiterverarbeitung in einem GUI, A

Zur Vereinfachung koennten wir nun auf C zugunsten von B mit expliziter
Zeitzonenangabe verzichten.

Gibt es einen Anwendungsfall fuer xmllist friendly? Oder schaut sich der
Anwender dann nicht gleich lieber den Output von list an?

Grüße,
Boris

[Kai 'wusel' Siering]

Moin,

Dr. Boris Neubert wrote:

> Zeitdarstellungen:
> A. Gleitkommazahl= Sekunden seit der Unix-Epoche (was time liefert)
> (funktioniert mit perl 5.12 auch noch nach 2038 und auf Macs ab MacOS X)

time liefert doch keinen Gleitkomma-, sondern Ganzzahlwert? Und: time
liefert UTC. Daraus folgt, daß vorgegeben sein muß, wie der Wert von time
mittels localtime/gmtime normiert wird. Oder?

> B. ISO8601 mit optionaler Zeitzonenangabe, wobei bei fehlender Zeitzone
> die Einstellung des Systems verwendet wird, wo fhem laeuft

Woher weiß ich, um welche Zeitzone es sich handelt? Muß ich das überhaupt
wissen oder reicht es nicht zu definieren "ohne Zeitzone = lokale Zeit".

Mich stört "die Einstellung des Systems verwendet wird": wer verwendet?
Wozu muß man überhaupt etwas "verwenden"? Reicht nicht die Kenntnis, daß
es lokale Zeit ist, aus?

> C. Benutzerdefiniertes Zeitformat mit optional definierter
> Zeitzonenangabe, wobei bei fehlender Zeitzone die Einstellung des
> Systems verwendet wird, in dessen Kontext die Ausgabe zum Benutzer erfolgt

Ich halte das in FHEM selbst für überflüssig. ISO8601 ist a) eindeutig und
b) menschenlesbar sowie c) nur marginal anders, als das, was FHEM seit jeher
Menschen vorgeworfen hat. KISS => nur A, B.
kai

[Dr. Boris Neubert]

Kai 'wusel' Siering schrieb:

> time liefert doch keinen Gleitkomma-, sondern Ganzzahlwert? Und: time
> liefert UTC. Daraus folgt, daß vorgegeben sein muß, wie der Wert von time
> mittels localtime/gmtime normiert wird. Oder?

Stimmt, time liefert Sekunden als Ganzzahl. localtime benutzt actime(3),
welcher sich wiederum beim Betriebssystem bedient.

>> B. ISO8601 mit optionaler Zeitzonenangabe, wobei bei fehlender Zeitzone
>> die Einstellung des Systems verwendet wird, wo fhem laeuft
>
> Woher weiß ich, um welche Zeitzone es sich handelt? Muß ich das überhaupt
> wissen oder reicht es nicht zu definieren "ohne Zeitzone = lokale Zeit".

Genau das meinte ich. Lokale Zeit= Zeit der CPU, auf der das Programm
laeuft.

>> C. Benutzerdefiniertes Zeitformat mit optional definierter
>> Zeitzonenangabe, wobei bei fehlender Zeitzone die Einstellung des
>> Systems verwendet wird, in dessen Kontext die Ausgabe zum Benutzer
>> erfolgt
>
> Ich halte das in FHEM selbst für überflüssig. ISO8601 ist a) eindeutig und
> b) menschenlesbar sowie c) nur marginal anders, als das, was FHEM seit
> jeher
> Menschen vorgeworfen hat. KISS => nur A, B.

Fein!

Ich habe, ohne Variante C, die Entscheidungsvorlagen E6 und E7 in

http://fhemwiki.de/index.php/DevelopmentGuidelines

eingestellt. Koennen wir zur Abstimmung schreiten oder muessen wir noch
an den Moeglichkeiten feilen?

Gruesse,
Boris

[Rudolf Koenig]

> Stimmt, time liefert Sekunden als Ganzzahl. localtime benutzt
> actime(3), welcher sich wiederum beim Betriebssystem bedient.

Andererseits mit "use Time::HiRes qw(gettimeofday);" liefert gettimeofday
in "int" context ein Fliesskommazahl zurueck, und das wird in fhem auch
zunehmend ausgenutzt.

> >>B. ISO8601 mit optionaler Zeitzonenangabe, wobei bei fehlender Zeitzone
> >>die Einstellung des Systems verwendet wird, wo fhem laeuft

Koennte jemand pruefen, ob gnuplot ISO8601 kann? Ich persoenlich mag ISO8601
nicht, da mich das T in der Mitte daran hindert, die Zeit und Datumskomponente
schnell zu erfassen. Bin mit dem Problem nicht alleine, in einem beruflichen
Projekt haben wir deswegen T durch _ ersetzt.

[Kai 'wusel' Siering]

Hi,

Rudolf Koenig wrote:

> Ich persoenlich mag ISO8601
> nicht, da mich das T in der Mitte daran hindert, die Zeit und Datumskomponente
> schnell zu erfassen. Bin mit dem Problem nicht alleine, in einem beruflichen
> Projekt haben wir deswegen T durch _ ersetzt.

Äh, arbeitest Du als "Senior Visual Grep"? ;)
kai

[Rudolf Koenig]

> >schnell zu erfassen. Bin mit dem Problem nicht alleine, in einem beruflichen
> >Projekt haben wir deswegen T durch _ ersetzt.
>
> Äh, arbeitest Du als "Senior Visual Grep"? ;)

Immer wieder. Diese SAP oder/und J2EE Logfiles sind schrecklich, und ich weiss
am Anfang der Fehlersuche nicht, wonach ich via grep suchen soll :) Da hilft es
schon, wenn man die Uhrzeit beim anschauen auch wahrnimmt.

[Dr. Boris Neubert]

Rudolf Koenig schrieb:

> Andererseits mit "use Time::HiRes qw(gettimeofday);" liefert gettimeofday
> in "int" context ein Fliesskommazahl zurueck, und das wird in fhem auch
> zunehmend ausgenutzt.

Ist in der Entscheidungsvorlage dahingehend beruecksichtigt, dass der
Verwender einer maschinenlesbaren Zeit damit umgehen koennen muss, wenn
er eine Fliesskommazahl vorfindet.

> Koennte jemand pruefen, ob gnuplot ISO8601 kann? Ich persoenlich mag ISO8601
> nicht, da mich das T in der Mitte daran hindert, die Zeit und Datumskomponente
> schnell zu erfassen. Bin mit dem Problem nicht alleine, in einem beruflichen
> Projekt haben wir deswegen T durch _ ersetzt.

ISO8601: set timefmt '%Y-%m-%dT%H:%M:%S' funktioniert, und zwar
unabhaengig davon, ob die optionale Zeitzonenangabe anhaengt oder nicht
(getestet mit Gnuplot v4.2 pl3)

Sekunden seit der Unix-Epoche: set timefmt '%s' (nicht getestet)

Gruesse,
Boris

[Dr. Boris Neubert]

Hallo,

die Abstimmung ueber die Zeitdarstellung wurde gestartet.

E6:

Folgende Zeitdarstellungen sind grundsaetzlich zulaessig:

A. Zahl der Sekunden seit der Unix-Epoche (was time liefert); auch wenn
time eine Ganzzahl liefert, muss der Verwender damit rechnen, eine
Gleitkommazahl vorzufinden. Das ist z.B. dann der Fall, wenn fuer die
Zeibestimmung hoeheraufloesende Funktionen (z.B. Time::HiRes) zum
Einsatz kamen und Sekundenbruchteile mitgespeichert wurden.

Hinweis zu potentiellen Problemen:

* Ab perl 5.12 ist das Jahr-2038-Problem in Perl beseitigt.
* Ab MacOS X liefert time auch auf Macs die Zahl der Sekunden seit
der Unix-Epoche (statt seit Anfang 1904)

B. ISO8601 mit optionaler Zeitzonenangabe, wobei bei fehlender Zeitzone

die lokale Zeitzone des fhem-Servers gilt

B'. Wie B., wobei jedoch zur besseren Lesbarkeit das T durch einen
Unterstrich ersetzt wurde.

C. Etwas anderes (bitte kommentieren).

Fuer jede der 4 Varianten kann mit Ja oder Nein abgestimmt werden. Die
Entscheidung fuer B oder B' faellt danach, welche der beiden Varianten
die meisten Stimmen erhaelt. Ansonsten gilt als angenommen, was mehr Ja-
als Nein-Stimmen hat.


E7:

Die Zeitdarstellungen werden wie folgt verwendet:

* Zur Programmlaufzeit in Variablen immer A
* In Konfigurationsdateien, insbesondere save-file, immer B
* In Logs, die fuer den Menschen bestimmt sind, B
* In Logs, die fuer die Maschine bestimmt sind, also z.B. bei

Weiterverarbeitung in einem GUI, A

* In Listen (list, xmllist friendly), die fuer den Menschen bestimmt
sind, B
* In Listen (xmllist), die fuer die Maschine bestimmt sind, also

z.B. bei Weiterverarbeitung in einem GUI, A

Die Unterscheidung zu den Logs wird noch zu diskutieren sein.

Hinweise zu gnuplot: set timefmt '%Y-%m-%dT%H:%M:%S' (ISO8601)

funktioniert, und zwar unabhaengig davon, ob die optionale

Zeitzonenangabe anhaengt oder nicht (getestet mit Gnuplot v4.2 pl3).
Fuer die Sekunden seit der Unix-Epoche: set timefmt '%s' (nicht getestet).

Es gilt als angenommen, was mehr Ja- als Nein-Stimmen hat.

Die Umfrage laeuft bis Donnerstag, 13.05.2010, 18 Uhr.

Viele Gruesse,

[Dr. Boris Neubert]

Hallo,

hier die Ergebnisse der Abstimmung:

E6: Zulaessige Zeitdarstellungen
A. Sekunden seit der Unix-Epoche 4:0
B. ISO8601 mit optionaler Zeitzonenangabe 3:1
B'. wie B, jedoch _ statt T 2:2
C. Etwas anderes (bitte kommentieren) 0:4

E7: Verwendung der Zeitdarstellungen
1. In Variablen A 4:0
2. In Konfig B oder B' 3:1
3. Fuer den Menschen B oder B' 3:1
4. Fuer Maschinen A (Frontend uebersetzt selbst) 3:1
5. In Listen fuer Menschen B oder B' 4:0
6. In Listen fuer Maschinen A 3:1

Damit haben wir folgendes Ergebnis:

- Zeitdarstellung in Variablen und fuer Maschinen (Frontend): Sekunden
seit der Unix-Epoche
- Zeitdarstellung in Konfigurationsdatei (fhem.conf, fhem.save) und fuer
den Menschen: ISO8601 mit optionaler Zeitzonenangabe (bei fehlender
Zeitzone ist die lokale Zeitzone des Servers gemeint)

Die Ergebnisse habe ich in

http://fhemwiki.de/index.php/DevelopmentGuidelines

dokumentiert.