#datetimes

and even if it were abolished internationally tomorrow, it would still be necessary to maintain existing code and continue handling it in new code when working with any datetimes prior to abolishing it. just like how even now, the utc offset for “US Eastern” is -4:56:02 instead of -5:00 when working with datetimes prior to 18 November 1883 at 12:03:58 PM, because that was New York’s local time prior to actually establishing Eastern Standard Time in 1883 (which can still cause unexpected problems even when you’re not handling very old datetimes, especially if you’re using pytz lol)

Meta: (manually sets correct date with a fictitious approximate time to make the download work.)

* log everything, indefinitely archive. * globally-unambiguous datetimes. * put sensors everywhere, especially for temperature. * sensible thermal designs. * options for slowing down things. * allow slowing down and speeding up parts individually. * no planned obsolescence. * use adaptable, replaceable, amendable interfaces. * indefinitely free as much as possible. well-known protocols. * keep and share all significant history. * no so-called "real names" (public legal names) asked nor encouraged. * document. abstract designs; concretely technical; user guides. * exacting references. minimise needed testing of ambiguities. * set up somewhere to receive reports, with few requirements. * options options options everywhere. at several levels.

oh. oh good.

Found after the earlier review that, apparently, out of the two "GMT" settings, there's one with some sort of seasonal timezone changes (labelled "(GMT) Greenwich Mean Time : Dublin, Edinburgh, London", internally selecting "Europe/Dublin") and another that apparently doesn't have any of those (labelled "(GMT) Casablanca, Monrovia", internally selecting "Africa/Casablanca"). Speculatively then, all the datetimes formatted (in ISO 8601) on this blog, which were previously marked as "local", will now stay as UTC permanently. Hence they will now be marked with the 'Z' (as in ISO 8601) to indicate this.

It's only that datetime stamps in all entries appear to be controlled by that one "Timezone" setting on www.tumblr.com/blog/NAME/settings which unfortunately doesn't clearly indicate whether and in what way seasonal timezone changes (incl. "daylight saving time", "summer time") are handled. The datetime stamps on the most recent entries imply that the selected "GMT" setting actually uses +01:00 currently, not +00:00 (ie UTC). Need further testing to find out whether the current effective timezone trivially determines the offset used with all datetime stamps, or whether seasonal change rules of the selected timezone are applied in a proleptic manner so that datetime stamps of specific entries are constant across the year while the same selected setting is constant (entries would then have local times of different effective timezones depending on when they were published). Don't know which is the worse. However, seasonal timezone changes along with unmarked local datetimes are clearly at the root of this; unsurprisingly, both are bad. There does not appear to clearly be any UTC setting that doesn't use any seasonal timezone changes. The tentative examination of the themes mechanism yielded no way to mark local datetimes with their effective timezone. Presumably, no information is stored on the timezone used by the author of an entry while submitting it. All right, there is not a lot of timezone handling that could be worse, apart from permanent corruption of the metadata. Not particularly happy with it being severely inaccessible, though.