search

preaction / Statocles

Static website CMS
http://preaction.me/statocles
Other
84 stars 33 forks source link

Blog posts don't appear in certain time zones (t/command/create.t fails) #474

Closed preaction closed 8 years ago

preaction commented 8 years ago

When you're in a UTC+ timezone (say, UTC+12 why not), and you have a post for 2016-01-05, if it's before noon (00:00 UTC), your post won't show up.

This manifests as a failure in t/command/create.t: The blog post created is for today, but if it's before 00:00 UTC, the blog will only deploy yesterday's content.

This is because DateTime::Moonpig, which we use for finding today's date, defaults to the UTC time zone. In this instance, we would really prefer localtime.

kentfredric commented 8 years ago

we would really prefer localtime.

Can you expand on what this means? Myself, where possible, I prefer consumers to see time in UTC, because my localtime is hardly ever relevant to anyone who is not me, so I opt to publish time related data in UTC, because at least its both a fair baseline, and a commonly known one.

( And being +12h off UTC works really well when you think in 12-hour clock as long as you ignore what day it is ;) )

preaction commented 8 years ago

The blog works mostly on dates and avoids time altogether. When determining "today's date", I think it's better to use localtime. This date is used to determine which posts to show, allowing pre-dating of posts in the future that then simply need a statocles deploy to publish.

preaction commented 8 years ago

Though, I should add, when it comes to a Calendar-like app, date/time and time zone will matter greatly, and then you'll have to be able to choose what timezone to display the human-readable date/time as (using <time> elements to provide the ISO8601 UTC timestamp for machines)

kentfredric commented 8 years ago

This date is used to determine which posts to show, allowing pre-dating of posts in the future that then simply need a statocles deploy to publish.

IME, that seems like a possible job for a plugin/role if people want that behaviour, but I'm not sure how hard that would be to implement.

"Future dated posts don't turn up" seems understandable once its explained, but it seems kinda surprising behaviour if you've not had somebody explain that to you.

preaction commented 8 years ago

That may be, but it's been a feature for quite a while now, it's in the blog's docs, and I make extensive use of it. Granted, that was before the status attribute (which remains meaningless for the blog at the moment). The fun part about moving that feature into a plugin is "should that plugin be in new sites by default" and "how do we tell existing users how to re-enable the feature"?

I'm willing to add a warning when a post is ignored for being pre-dated. Indeed, I'd say any content that exists but is not being deployed should get a warning for whatever reason it might be, desired or not. Alternatively, content being ignored for documented reasons could just be an "info" level (a single statocles build -v will reveal info-level logging).

But, those things are other tickets. This is about making sure the test doesn't fail to install due to the position of the sun in the sky, and the computer on the Earth.