6230km sind es insgesamt, 43km mehr als letzte Woche. Und hey, ich habe nur einen Tag gearbeitet!
|
|||||
|
6230km sind es insgesamt, 43km mehr als letzte Woche. Und hey, ich habe nur einen Tag gearbeitet! Gestatten, das ist Horst. Horst Voll. Manche nennen ihn auch anders. Und auch wenn er immer wieder anders aussieht, so begegnet er mir doch fast täglich. Heute jedoch war er in Bestform. Was ein Drama. Angeregt durch die neue Version der Android-App habe ich heute das System aktualisiert. Was ein Drama. Immerhin war ich diesmal pingelig genug, um vorher ein komplettes Backup zu machen. War eh mal wieder fällig. Und siehe da, es ging ausnahmsweise nicht problemlos. Das Frontend, also das, was ihr liebe Leser seht, muckte nicht. Dafür aber war die Adminseite, also das, womit ich u.a. dies hier schreibe, tot. Weißer Bildschirm, mehr nicht. Erste Abhilfe: Das gerade gemachte Backup aufspielen. Naja, besser gesagt einfach alle php und js-Dateien von der lokalen Platte wieder auf den Server bügeln. Immerhin, die Adminseite erschien wieder halbwegs. Besser gesagt ein Hinweis, daß man nach dem Upgrade nun auch noch die Datenbank aktualisieren müsse. Aha, hatte ich bisher nicht. Angeklickt. Weißer Bildschirm. Klarer Fall, die Datenbank ist jetzt bei 3.3, das System jedoch bei 3.2.1, kann ja nicht gehen. Zurück auf 3.3 – äh Moment! Ja genau, die 3.3 hatte ich natürlich nicht gesichert. Zurück zu den Wurzeln, Paket für die Grundinstallation runterladen und auf den Server schieben. Weißer Bildschirm. Googlen. Warum nicht mal googlen? Und siehe da, es könnte an den Plugins liegen. Da waren eh einige aktualisierbar, aber ich Trottel musste ja erst einmal das System selbst aktualisieren. Deaktivieren kann man sie zum Glück ganz leicht, indem man ihre Verzeichnisse löscht, verschiebt oder einfach umbenennt. So war Postie1 schnell als Unruhestifter ausgemacht. “WordPress 3.3 Postie” führte dann auch schnell zu der Info, die ich vorher hätte haben sollen: Erst Postie aktualisieren, dann WordPress. Weil letzteres sonst abkackt. “Erfahrung ist das, was man bräuchte kurz bevor man sie macht.” Wie wahr dieser Satz doch heute mal wieder ist.
Mal sehen, ob das Einstellen von Datum und Uhrzeit jetzt richtig klappt. Also nicht wundern. 6187km, immerhin 37km in der vergangenen Woche. Eigentlich war dieser Artikel dafür gedacht, wie ich mit dem doch ganz brauchbaren neuen Scanner künftig bei der Filmentwicklung FotoCDs oder gar Abzüge überflüssig mache. Eigentlich. 6150km, 32mehr als letzte Woche. Dreckswetter und zwei freie Tage… 6118km liegen an, gerade mal 23km mehr als in der Vorwoche. Zwei freie Tage, am Samstag chauffiert, macht gerade mal 3 Fahrtage und somit etwas mehr als 7,6km pro Tag. Ich schäm mich ja schon… Die letzten Tagen war ich zumindest hier fleißig. Gut, die Fenster und Böden sind auch geputzt. Jedenfalls gibts einiges an neuen alten Reiseberichten und etliche Bilder. Neue Artikel (gleich mit Bildern):
Bilder gibt es zu folgenden Artikeln neu: Viel Spaß beim Lesen! Holschi und Phil, hier sind endlich einige der vermissten Bilder! Ich krieg da echt mal wieder Pickel am Arsch. Warum müssen Windows und die dafür erstellten Programme so sorglos mit Uhrzeiten und Zeitzonen umgehen? Gut, die Digitalkameras, um die es gerade geht, kennen keine Zeitzoneneinstellung. Schade, das sollte langsam mal obligat werden. Denn Windows macht es inzwischen eigentlich schon ganz gut. Die Uhrzeit wird einmal eingestellt und auf Reisen genügt es, die Zeitzone zu ändern. Dateidaten etc. passen sich automatisch an wie auch Termine im Kalender. So weit, so schön. Jetzt müsste man nur noch beim Import von Bilddaten sagen können, auf welche Zeitzone sich deren Angaben beziehen. Oder überhaupt: Alles wird mit GMT gepeichert, aber eben in der lokal eingestellten Zeitzone angezeigt. Und es müsste bei den Dateieigenschaften die Möglichkteit geben, die Zeitzone der Erstellung zu verändern. Und als default wird halt die lokale Zeitzone genommen, wenn man die Bilder importiert. Beispiel? Datei wird ohne Zeitzonenkontext (Kamera) um 08:00Uhr Lokalzeit erstellt. Beim Import wird berücksichtigt, daß man sich in GMT+3 befindet und eben mit 05:00 Uhr GMT gespeichert. Und dem Hinweis, daß die lokale Zeitzone eben GMT+3 war. Und so sollte es auch möglich sein, die lokale Uhrzeit der Erstellung per default anzuzeigen. Denn gerade bei Bildern wird es ansonsten verwirrend, wenn um Mitternacht (GMT) entstandene Bilder eine Gefängnisinsel im strahlenden Sonnenschein zeigen. Andererseits ist es einer Tabellenkalkulation egal, daß es hier 18 Uhr war, als sie in New York mittags bearbeitet wurde. Äh ja, genug gefaselt. Ich postuliere hiermit, daß bei künftigen System alle Uhrzeiten in GMT geführt werden, zeitzonensensitiv sind und kontextsensitiv bzw. wählbar die lokale Uhrzeit der Erstellung oder eben die Uhrzeit der aktuell eingestellten Zeitzone angezeigt werden. Wie ich darauf mal wieder komme? Ich bearbeite mal wieder unsere USA-Reiseberichte, damit das endlich fertig wird. Picasa hat es geschafft, bei einem Bild, das um 17:02:00 Uhr Ortszeit (Arizona) aufgenommen wurde, plötzlich 14:02:00 Uhr anzuzeigen. Beim folgenden Bild, aufgenommen, 17:02:30 Uhr, wird 16:02:30 Uhr angezeigt. Was auch nicht richtig ist, selbst wenn man die Sommerzeit mit ins Spiel bringt. Aber daß die Bilder plötzlich zwei Stunden und 30 Sekunden auseinander sind statt nur 30 Sekunden, das geht gar nicht. Mal abgesehen von der Kür: Der Aufnahmeort Arizona kennt keine Sommerzeit. D.h. der genaue Aufnahmeort im Navajoreservat offiziell dann doch, was in der Praxis aber nicht auffällt. Wie man sieht, ein kompliziertes Thema. Zumal an diesem speziellen Ort ein paar km Autofahrt eine Zeitverschiebung um eine Stunde bescherten. Ich will eine Normalzeit auf allen Systemen, die entsprechend respektiert wird!
Grummel…. |
|||||
|
Copyright © 2004-2012 Peter Weller - All Rights Reserved 50 queries. 0,904 seconds. |
|||||
Neueste Kommentare