Drummer is going through that shaking-out period that new software experiences, esp. software developed "live" in-the-moment. My posts from October 25 have suddenly disappeared, and this one from the future has yet to show up on the front page. Problems are lurking down in the machinery responsible for deciding when time has arrived for a dated post to be published. The machinery has been ambivalent, unsure or inconsistent in handling timezone differences. #
Time is time and constant, but my time relative to your time is different. Being a good 12 hours ahead of New York and 8 hours ahead of GMT, my days start before their's. But machinery stuck on EDT or GMT, or inconsistent in its internal bookkeeping practices, might erroneously conclude that a post is not publishable.#
Coding wise and conceptually speaking, none of this is difficult to solve, but on the practical level these kinds of date-time calculations fall into a class of programming challenges that can confound the most capable and experienced software developers.#
I think this is due, in part, to shortcomings in computer languages to expose a full-stack of APIs, from the high-level "solve-the-common-use-case" to low-level "time-is-complicated" APIs. Most languages do not provide a good enough high-level API. There's a reason why one often looks for a third-party date-time library.#
(Money and Currency are another big omission in most computer languages, which is surprising given how central they are to our world.)#
I am not sure what the underlying issue in Drummer is or entirely clear on how the publisher is intended to work, but from my experience with date-time problems in general, I know they can also result from overloading data with too many meanings or responsibilities, especially when the system needs to make decisions based on both meanings at the same time.#
One way around this is to separate out the blog's local time from the blog's publishing time.#
"Blog time" would be expressed in my timezone, and "Publishing time" would be expressed always in UTC. The two datums are tracked together but independently in the OPML.#
The publishing machinery would use "Blog time" to create URLs (i.e. ".../2021/10/24.html") and use "Publishing time" to decide when the entry can be made available; the publisher would always run in UTC.#
The two values for each would be calculated when "Build my blog..." is run, and they would be effectively immutable values. No other conversion would be done later, as the publishing system would just read the values, do a bit of date comparison, and that would be that.#
Even if the Old School publisher actually dynamically renders the blog (not publishes static files), the model would work equally well:#
1. Request for ".../2021/10/26.html" is received.2. Does it exist? Check entries for "Blog time" 3. If it exists, is it publishable? Check "Publishing time"4. If yes to both, then render the page. 5. Else handle 404
The data being immutable also means debugging is easier. (You can inspect the actual data used by the machinery to make its decisions without having to compute it first.)#
The data being pre-computed and separated into two datums eliminates a whole level of second-order debugging to determine where and when in the code the local time is not being converted to UTC for purposes of publishing and being converted back to local time for purposes of URL creation. The system's state is constant in this regard.#
The two values can be stored in the OPML or, perhaps, in a separate "publishing" manifest. The manifest would be created by the publishing machinery on receipt of the "Build my blog..." command.#
Drummer is going through that shaking-out period that new software experiences, esp. software developed "live" in-the-moment. My posts from October 25 have suddenly disappeared, and this one from the future has yet to show up on the front page. Problems are lurking down in the machinery responsible for deciding when time has arrived for a dated post to be published. The machinery has been ambivalent, unsure or inconsistent in handling timezone differences. #
Time is time and constant, but my time relative to your time is different. Being a good 12 hours ahead of New York and 8 hours ahead of GMT, my days start before their's. But machinery stuck on EDT or GMT, or inconsistent in its internal bookkeeping practices, might erroneously conclude that a post is not publishable.#
Coding wise and conceptually speaking, none of this is difficult to solve, but on the practical level these kinds of date-time calculations fall into a class of programming challenges that can confound the most capable and experienced software developers.#
I think this is due, in part, to shortcomings in computer languages to expose a full-stack of APIs, from the high-level "solve-the-common-use-case" to low-level "time-is-complicated" APIs. Most languages do not provide a good enough high-level API. There's a reason why one often looks for a third-party date-time library.#
(Money and Currency are another big omission in most computer languages, which is surprising given how central they are to our world.)#
I am not sure what the underlying issue in Drummer is or entirely clear on how the publisher is intended to work, but from my experience with date-time problems in general, I know they can also result from overloading data with too many meanings or responsibilities, especially when the system needs to make decisions based on both meanings at the same time.#
One way around this is to separate out the blog's local time from the blog's publishing time.#
"Blog time" would be expressed in my timezone, and "Publishing time" would be expressed always in UTC. The two datums are tracked together but independently in the OPML.#
The publishing machinery would use "Blog time" to create URLs (i.e. ".../2021/10/24.html") and use "Publishing time" to decide when the entry can be made available; the publisher would always run in UTC.#
The two values for each would be calculated when "Build my blog..." is run, and they would be effectively immutable values. No other conversion would be done later, as the publishing system would just read the values, do a bit of date comparison, and that would be that.#
Even if the Old School publisher actually dynamically renders the blog (not publishes static files), the model would work equally well:#
1. Request for ".../2021/10/26.html" is received.2. Does it exist? Check entries for "Blog time" 3. If it exists, is it publishable? Check "Publishing time"4. If yes to both, then render the page. 5. Else handle 404
The data being immutable also means debugging is easier. (You can inspect the actual data used by the machinery to make its decisions without having to compute it first.)#
The data being pre-computed and separated into two datums eliminates a whole level of second-order debugging to determine where and when in the code the local time is not being converted to UTC for purposes of publishing and being converted back to local time for purposes of URL creation. The system's state is constant in this regard.#
The two values can be stored in the OPML or, perhaps, in a separate "publishing" manifest. The manifest would be created by the publishing machinery on receipt of the "Build my blog..." command.#
Copyright 2021 MSD
Last update: Tuesday October 26, 2021; 7:26 PM EDT.