#datetimes

[lesbianchemicalplant]

timezones themselves require a lot of time and care regardless, but daylight savings has cost programmers so much additional time and energy.....

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)

[vaguely-none]

can i run ntpd on this mind?

[vaguely-none]

mobile: hang

Meta: take out its power

Meta: restart it

mobile: datetime reset to 1980

Meta: unlock it

router: connected to fixed line net link

mobile: connect to router's access point

mobile: can't connect to mobile network

mobile: doesn't sync time using wlan

mobile: (would sync with mobile networks)

Meta: hmm

Meta: browse the repo

Meta: find NTPSync application

Meta: tap to install newest version

mobile: aborts download

mobile: ssl certificate isn't valid until many years in the future :^y

Meta: grargh!!!

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

[vaguely-none]

Meta design principles

* 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.

[roomthily]

As it turns out, Excel “supports” two different date systems: one beginning in 1900 and one beginning in 1904. Excel stores all dates as floating point numbers representing the number of days since a given start date, and Excel for Windows and Mac have different default start dates (January 1, 1900 vs. January 1, 1904). Furthermore, the 1900 date system purposely erroneously assumes that 1900 was a leap year to ensure compatibility with a bug in—wait for it—Lotus 1-2-3.

Kara Woo (Data Pub)

oh. oh good.

[lohauserdike]

Keeping the Unix time numbers just in case tumblr should mess up timezones again, though.

[lohauserdike]

Timezone setting that presumably uses +00:00 permanently

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.

[lohauserdike]

Seems that timezone handling is not all bad actually.

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.