nicht angemeldet
Table -> Kalender
0 0 
Orlok
0 
Gunnar Bittersmann
0 0 Gunnar Bittersmann
0 0 
Auge
0 Gunnar Bittersmann
1
Table -> Kalender
Hallo,
ich hätte eine Frage zur Zeitdarstellung generell. Ich möchte wie in diesem Image dargestellt: Image Zeiten darstellen. Im diesem Image werden 24h eines Tages angezeigt und ich möchte Zeiten einstellen können (der grüne Balken im Image). Ich programmiere das Frontend mit AngularJS. Meine Frage wäre, obs dafür schon eine fertige Komponente gibt und wenn ja wo. Danke für Eure Hilfe! Besten Dank, Hannes
-
Hallo,
ich habe jetzt einiges an research betrieben aber leider nichts passendes gefunden. Ich werde wahrscheinlich nicht drum herum kommen, dass ich mir einen Kalender selber programmiere. Was ich brauche ist auf der x-Achse die Tage / den Tag UND zusätzlich die Stunden auf der X- Achse (in den einzelnen Tages Zellen) und auf der y- Aches Personen. . Sowas hab ich leider nicht gefunden. Ich hab jetzt auch kein Problem, dass ich mir das selber Programmiere, mein aktuelles Problem ist aber, dass ich nicht weiß, wie ich die Tage und das Datum bestimmen kann - wie Implementiert man so eine Kalenderfunktion. Wenn z.B. angenommen heute Sonntag, der 28.08.2015 wäre, wie kann ich die Infos herbekommen, dass der August 31 Tage hat und am Donnerstag der 01.09 anzuzeigen ist. Speichert man sowas hardcodiert ab oder hat man da eine Logik hinterlegt in Javascript / AngularJS. Wäre euch dankbar für jeden Hinweis in diese Richtung. Danke! Hannes
Hallo,
ich hätte eine Frage zur Zeitdarstellung generell. Ich möchte wie in diesem Image dargestellt: Image Zeiten darstellen. Im diesem Image werden 24h eines Tages angezeigt und ich möchte Zeiten einstellen können (der grüne Balken im Image). Ich programmiere das Frontend mit AngularJS. Meine Frage wäre, obs dafür schon eine fertige Komponente gibt und wenn ja wo. Danke für Eure Hilfe! Besten Dank, Hannes
-
Hallo,
[…] oder hat man da eine Logik hinterlegt in Javascript / AngularJS.
Es gibt in JavaScript das Date-Objekt, aber ob dir das in deinem Fall wirklich weiterhilft musst du selbst beurteilen, denn es ist dabei zu berücksichtigen dass JavaScript ja clientseitig ausgeführt wird, sprich, die Ausgaben von Date sich auf die Systemzeit des Clients beziehen, und die kann sich natürlich von der des Servers unterscheiden.
Das heißt, wenn du unbedingt einheitliche Ausgaben brauchst, wirst du das wohl soweit ich weiß serverseitig lösen müssen, - und sollte dem so sein, könntest du einmal einen Blick auf diese Seite werfen.
Gruß,
Orlok
-
@@Hannes Weninger
wie Implementiert man so eine Kalenderfunktion. Wenn z.B. angenommen heute Sonntag, der 28.08.2015 wäre, wie kann ich die Infos herbekommen, dass der August 31 Tage hat und am Donnerstag der 01.09 anzuzeigen ist.
In keiner Umgebung rechnest du mit Jahr/Monat/Datum(/Stunde/Minute), sondern immer mit dem Timestamp (Zeitstempel). Die oft zugrundeliegende Unix-Zeit fängt am 1970-01-01T00:00Z bei 0 an, Sekunden zu zählen (ohne Schaltsekunden zu berücksichtigen). JavaScript verwendet denselben Nullpunkt, zählt aber in Millisekunden.
Um von Timestamp des Sonntags zu dem des folgenden Donnertags (gleiche Uhrzeit) zu kommen, musst du 4 Tage addieren – umgerechnet in Sekunden also 4 × 24 × 60 × 60 bzw. in Millisekunden 4 × 24 × 60 × 60 × 1000.
Die Umrechnung von Timestamp in von Menschen gebräuchliche Datumsangabe findet bei der Ausgabe statt, nicht früher. Dafür bieten Programmiersprachen entsprechende Methoden (Funktionen).
Andersrum wird sofort nach der Eingabe eine Datumsangabe in einen Timestamp umgerechnet – auch dafür gibt es entsprechende Methoden.
Jahr, Monat, Datum, Stunde, Minute sind Dinge, die innerhalb eines Programmes (oder einer Datenbank) nicht vorkommen.
LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein.-
Besten Dank euch beiden für die Info, das hat mir schon weitergeholfen. Ich bin mir jetzt noch nicht sicher, ob ich das clientseitig oder serverseitig machen soll - wie von euch erwähnt.
Client- Seitig: mein Programm wird zwar nur in Mitteleuropa eingesetzt aber Browsereinstellungen sind ja dann auch ein Problem und ich wär halt für andere Zeitzonen nicht offen.
Server-Seitig: es müssen halt einige Daten mehr übertragen werden - is aber soweit ich das jetzt seh nicht so viel (nur eben die Timestamp für die Woche)
Wie würdet ihr das machen, würdet ihr es Clientmäßig machen, damits noch performater ist oder server seitig, wo die Logik für jeden Client einheitlich ist und auch eher leichter zu implementieren ist.
Viele Dank! Hannes
@@Hannes Weninger
wie Implementiert man so eine Kalenderfunktion. Wenn z.B. angenommen heute Sonntag, der 28.08.2015 wäre, wie kann ich die Infos herbekommen, dass der August 31 Tage hat und am Donnerstag der 01.09 anzuzeigen ist.
In keiner Umgebung rechnest du mit Jahr/Monat/Datum(/Stunde/Minute), sondern immer mit dem Timestamp (Zeitstempel). Die oft zugrundeliegende Unix-Zeit fängt am 1970-01-01T00:00Z bei 0 an, Sekunden zu zählen (ohne Schaltsekunden zu berücksichtigen). JavaScript verwendet denselben Nullpunkt, zählt aber in Millisekunden.
Um von Timestamp des Sonntags zu dem des folgenden Donnertags (gleiche Uhrzeit) zu kommen, musst du 4 Tage addieren – umgerechnet in Sekunden also 4 × 24 × 60 × 60 bzw. in Millisekunden 4 × 24 × 60 × 60 × 1000.
Die Umrechnung von Timestamp in von Menschen gebräuchliche Datumsangabe findet bei der Ausgabe statt, nicht früher. Dafür bieten Programmiersprachen entsprechende Methoden (Funktionen).
Andersrum wird sofort nach der Eingabe eine Datumsangabe in einen Timestamp umgerechnet – auch dafür gibt es entsprechende Methoden.
Jahr, Monat, Datum, Stunde, Minute sind Dinge, die innerhalb eines Programmes (oder einer Datenbank) nicht vorkommen.
LLAP 🖖
Ist diese Antwort anstößig? Dann könnte sie nützlich sein.
-
@@Hannes Weninger
Wie würdet ihr das machen, würdet ihr es Clientmäßig machen, damits noch performater ist oder server seitig, wo die Logik für jeden Client einheitlich ist und auch eher leichter zu implementieren ist.
Kommt drauf an.
Sollen die Daten mit anderen geteilt werden? Dann muss es wohl über einen Server laufen. (Oder hattest du eine dezentrale Lösung im Sinn?)
Die Zeitzone hat damit rein gar nichts zu tun. Du hast noch nicht ganz verinnerlicht, was ein Timestamp ist.
1439139600 (Sekunden) bzw. 1439139600000 (Millisekunden, JavaScript) steht für 2015-08-09T19:00+02:00 (9. Aug. 2015 19:00 MESZ) genauso wie für 2015-08-09T17:00+00:00 (17:00 UTC) – weil es derselbe Zeitpunkt ist.
LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein.-
Hallo Gunnar,
Sollen die Daten mit anderen geteilt werden? Dann muss es wohl über einen Server laufen. (Oder hattest du eine dezentrale Lösung im Sinn?)
danke für deine Antwort. Einer der Usecases ist so, dass man in die Tabelle Zeiten eingeben kann, und diese dann in der Datenbank gespeichert werden. ICh würde eine Serverlösung auch preferieren - wegen der Performance hab ich noch ein paar bedenken.
LG Hannes
-
Hallo
Sollen die Daten mit anderen geteilt werden? Dann muss es wohl über einen Server laufen. (Oder hattest du eine dezentrale Lösung im Sinn?)
danke für deine Antwort. Einer der Usecases ist so, dass man in die Tabelle Zeiten eingeben kann, und diese dann in der Datenbank gespeichert werden. ICh würde eine Serverlösung auch preferieren - wegen der Performance hab ich noch ein paar bedenken.
Das beantwortet immer noch nicht Gunnars Frage. Ist „man“ eine Person mit seinem Kalender oder sind dies mehrere Personen, von denen jeder einzelne nur seinen eigenen Kalender hat oder sind es verschiedene Personen, die mit einem gemeinsamen Kalender arbeiten? Die Antwort entscheidet, ob die Datenhaltung und damit auch die Verarbeitung auf einem/dem Server stattfindet oder ob sie dem Client überlassen werden kann.
Das sagt allerdings nichts darüber aus, ob man die serverseitige Prüfung und Verarbeitung der Daten durch clientseitige Techniken unterstützen sollte oder nicht. Die Antwort lautet: Ja, das sollte man tun. Schon alleine wegen deines Balkens aus dem Eröffnungspostings wirst du JavaScript brauchen, wenn der Balken mehr sein und können soll, als eine statische Grafik zu sein.
Tschö, Auge
--
Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
Terry Pratchett, „Gevatter Tod“
-
-
-
-
-
Hallo Gunnar,
In keiner Umgebung rechnest du mit Jahr/Monat/Datum(/Stunde/Minute), sondern immer mit dem Timestamp (Zeitstempel).
Du kennst jedes System so genau, um das beurteilen zu können? Ich würde mir das nicht zutrauen ;)
Um von Timestamp des Sonntags zu dem des folgenden Donnertags (gleiche Uhrzeit) zu kommen, musst du 4 Tage addieren – umgerechnet in Sekunden also 4 × 24 × 60 × 60 bzw. in Millisekunden 4 × 24 × 60 × 60 × 1000.
Das ist falsch. Ein Tag hat (abhängig von Daylight-Saving) zwischen 23 und 25 Stunden, +/- ein paar Sekunden (abhängig von Schaltsekunden). Und genau das ist einer der Gründe, warum man nicht selber mit Sekunden rechnet, sondern die Bibliotheken der Umgebung verwendet, um mit Daten zu rechnen. Die trivial erscheinende Rechnerei mit Daten ist in Wahrheit ziemlich komplex. Und von Schaltjahren und Zeitzonen hab ich ja noch gar nicht angefangen… ;)
Jahr, Monat, Datum, Stunde, Minute sind Dinge, die innerhalb eines Programmes (oder einer Datenbank) nicht vorkommen.
Nee, moderne Date-APIs geben dir Methoden, um einzelne Tage/Monate/... zu addieren. Schau dir z.B. die Date-API von Ruby an:
require 'date' t = DateTime.now puts t # 14 days later puts t + 14 # 2 months later puts t >> 2Für JavaScript gibt es Moment.js. Für PHP verwendet man die DateTime-API. Ruby erweitert mit den Active-Frameworks die API gewaltig, so dass man auch sowas wie
Time.now + 2.daysschreiben kann. Java bringt eine ähnliche API mit, schau dir z.B. speziell dieadd-Methode an.Datums-Berechnungen will man nicht selber machen.
LG,
CK-
@@Christian Kruse
Um von Timestamp des Sonntags zu dem des folgenden Donnertags (gleiche Uhrzeit) zu kommen, musst du 4 Tage addieren – umgerechnet in Sekunden also 4 × 24 × 60 × 60 bzw. in Millisekunden 4 × 24 × 60 × 60 × 1000.
Das ist falsch.
Grmpf, ja. 96 Stunden später ergibt nicht immer dieselbe (lokale) Uhrzeit. Nämlich dann nicht, wenn sich die lokale Zeitzone ändert (Umstellung auf Sommenzeit und zurück). Ich hätte sagen sollen: gleiche Uhrzeit in UTC.
Ein Tag hat (abhängig von Daylight-Saving) zwischen 23 und 25 Stunden, +/- ein paar Sekunden (abhängig von Schaltsekunden).
Das ist aber auch nicht ganz richtig. Es gibt maximal eine Schaltsekunde amm Tag. Und zwar am 30. Juni oder am 31. Dezember 23:59:60 UTC. (Was bei uns schon der 1. Juli bzw. 1. Januar ist.) Das fällt also nicht mit der Sommerzeitumstellung zusammen, so dass Schaltsekunden das Intervall [23:00:00, 25:00:00] nicht erweitern. ;-)
Und Schaltsekunden fließen in die Unix-Zeit gar nicht mit ein.
| 2015-06-30T23:59:59Z | 1435708799 | 2015-06-30T23:59:60Z | gibt’s nicht | 2015-07-01T00:00:00Z | 1435708800
Von 2015-06-30T23:59:59Z bis 2015-07-01T00:00:00Z sind 2 Sekunden vergangen, laut Unix-Zeit jedoch nur eine.
LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein.-
Hallo Gunnar,
Ein Tag hat (abhängig von Daylight-Saving) zwischen 23 und 25 Stunden, +/- ein paar Sekunden (abhängig von Schaltsekunden).
Das ist aber auch nicht ganz richtig. Es gibt maximal eine Schaltsekunde amm Tag. Und zwar am 30. Juni oder am 31. Dezember 23:59:60 UTC. (Was bei uns schon der 1. Juli bzw. 1. Januar ist.) Das fällt also nicht mit der Sommerzeitumstellung zusammen, so dass Schaltsekunden das Intervall [23:00:00, 25:00:00] nicht erweitern. ;-)
Ja, da hast du recht, so genau hatte ich das jetzt nicht nachgeschaut. ;-) Mir ging es hauptsächlich darum, dass das rechnen mit Daten gar nicht so einfach ist und man das nicht zu Fuss machen will.
Und Schaltsekunden fließen in die Unix-Zeit gar nicht mit ein.
Jain. Die Zeit wurde für eine Sekunde angehalten bzw verging langsamer für die meisten Systeme, das ist das Standard-Vorgehen von
ntpd. Aber auch das muss man ggfls beachten.LG,
CK-
Hallo Christian,
Mir ging es hauptsächlich darum, dass das rechnen mit Daten gar nicht so einfach ist und man das nicht zu Fuss machen will.
Zu dem Thema hab ich mich gerade nochmal an zwei echt interessante Beiträge erinnert.
Der erste Beitrag dreht sich um die oft gemachten fehlerhaften Annahmen bzgl Zeit und Datum, der zweite Beitrag dreht sich um den Irrsinn von Zeitzonen. Beides sehr empfehlenswert.
LG,
CK-
@@Christian Kruse
Der erste Beitrag dreht sich um die oft gemachten fehlerhaften Annahmen bzgl Zeit und Datum, der zweite Beitrag dreht sich um den Irrsinn von Zeitzonen. Beides sehr empfehlenswert.
Fun to read/watch.
LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein. -
@@Christian Kruse
Zu dem Thema hab ich mich gerade nochmal an zwei echt interessante Beiträge erinnert.
Kam zufällig gerade übern Ticker: Daylight Saving Time Explained
LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein.
-
-
-
@@Gunnar Bittersmann
Und Schaltsekunden fließen in die Unix-Zeit gar nicht mit ein.
| 2015-06-30T23:59:59Z | 1435708799 | 2015-06-30T23:59:60Z | gibt’s nicht | 2015-07-01T00:00:00Z | 1435708800
Auch das nicht so ganz richtig. Sondern:
| 2015-06-30T23:59:59Z | 1435708799 | 2015-06-30T23:59:60Z | 1435708800 | 2015-07-01T00:00:00Z | 1435708800
Die Unix-Uhr wird umgestellt (automatisch, wenn die Uhr durch einen Service synchronisiert wird).
Im Gegensatz zur Umstellung auf Sommerzeit oder zurück, wo die Umstellung an der Zeitzone erkennbar ist
| 2015-03-29T00:59:59Z | 2015-03-29T01:59:59+01:00 | 01:59:50 MEZ | 2015-03-29T01:00:00Z | 2015-03-29T03:00:00+02:00 | 03:00:00 MESZ
ist die Umstellung der Unix-Uhr durch nichts erkennbar, d.h. der Zeitpunkt 1435708800 (besser gesagt die Zeitpunkte im Intervall [1435708800, 1435708801[) sind nicht eindeutig. Es kann Anwendungen geben, wo dies problematisch ist.
Quarzgesteuerte Uhren gehen sowieso falsch, bspw.:
| 2015-06-30T23:59:59Z | 00:00:02 | Uhr geht 3 Sekunden vor | 2015-06-30T23:59:60Z | 00:00:03 | | 2015-07-01T00:00:00Z | 00:00:04 | Uhr geht 4 Sekunden vor
Da fällt die Schaltsekunde nicht weiter auf.
LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein.-
Hallo Gunnar,
Auch das nicht so ganz richtig. Sondern:
| 2015-06-30T23:59:59Z | 1435708799 | 2015-06-30T23:59:60Z | 1435708800 | 2015-07-01T00:00:00Z | 1435708800
Die Unix-Uhr wird umgestellt (automatisch, wenn die Uhr durch einen Service synchronisiert wird).
Nein, die gängige Variante unter Unixoiden ist es, die Zeit zu verlangsamen bis sie wieder gleich auf ist mit der richtigen Zeit, siehe
ntpd. Das kann durchaus auch länger dauern als eine Sekunde. Das wird gemacht um doppelte Uhrzeiten bzw rückwärts laufende Zeit zu vermeiden: es gibt Anwendungen, die da sehr empfindlich gegen sind (z.B. der Dovecot).LG,
CK-
@@Christian Kruse
Nein, die gängige Variante unter Unixoiden ist es, die Zeit zu verlangsamen bis sie wieder gleich auf ist mit der richtigen Zeit, siehe
ntpd.Sag das mal der Wikipedia! ;-)
Ich hab dein Posting erst gelesen, nachdem ich meins geschrieben hatte.
LLAP 🖖
--
Ist diese Antwort anstößig? Dann könnte sie nützlich sein.-
Hallo Gunnar,
Sag das mal der Wikipedia! ;-)
Ne, sorry, mit der (naja, mindestens mit der deutschen Variante) habe ich abgeschlossen.
LG,
CK
-
-
-
-
-
-
-