Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SiteDateTime setting to filter published blog posts #859

Open
duracellko opened this issue Aug 2, 2019 · 8 comments

Comments

@duracellko
Copy link

commented Aug 2, 2019

Currently BlogPosts pipeline renders only posts, which have PublishedKey earlier than DateTime.Now.

I suggest to add setting named SiteDateTime (or GeneratedDateTime) with default value DateTime.Now. Then BlogPosts pipeline renders posts, which have PublishedKey earlier than SiteDateTime.

I see 2 use-cases, with providing this setting from command-line:

  1. Preview website with blog posts, which are planned to be published in next days.
  2. Possibility for correction, when building website on build server in different time zone.
@arebee

This comment has been minimized.

Copy link
Contributor

commented Aug 5, 2019

Are you going to use NodaTime throughout, or at least DataTimeOffset?

@duracellko

This comment has been minimized.

Copy link
Author

commented Aug 5, 2019

Are you going to use NodaTime throughout, or at least DataTimeOffset?

Good point , I will think about it. Although very first idea is that PublishKey and SiteDateTime are in same time zone. So no need to use DateTimeOffset or NodaTime. However, author can use those in config.wyam to transform/set either of the settings.

And here are some points to assume both values are in same time zone:

  1. PublishKey contains only date value, no time or time-zone information.
  2. It does not make much sense that PublishKey contains time part. If an author wants to change content every hour, then static site is not the right technology.
@arebee

This comment has been minimized.

Copy link
Contributor

commented Aug 5, 2019

It's not that I want to change the content every hour... but sometimes. I think this is a bad assumption, expecially in a CI/CD case where multiple people are working in a private repro on embargoed work, as an example.

@duracellko

This comment has been minimized.

Copy link
Author

commented Aug 6, 2019

This is my suggestion split to 3 steps:

Step 1: Published metadata

Actually this step is "no change". Currently Published metadata value is entered in format yyyy-MM-dd. So it contains only date information, but no time or time zone.

And I suggest to keep it that way. Other option would be to extend the metadata value to format yyyy-MM-dd HH:mm:ss zzz (Custom date and time format strings). However, in my opinion this should be avoided, because Published value "2019-08-06 21:05:21+7:00" is not correct. It is very unlikely that post was published at that exact time.

Step 2: SiteDateTime setting

It is possible to set setting value SiteDateTime. Value is of type date time optionally with time zone offset. For example in format: yyyy-MM-dd HH:mm:ss zzz.

Step 3: Filter unpublished blog posts

Only blog posts with Published metadata value earlier than SiteDateTime setting. If the setting is not specified, then DateTime.Now value is used (current behavior).
As Published value does not contain any time zone or offset information then only date time part is compared with SiteDateTime. Offset part of SiteDateTime is ignored.

Suggestions

This is my suggestion. Feel free to comment, which of the details should be different.

@duracellko

This comment has been minimized.

Copy link
Author

commented Aug 6, 2019

And this is proposed use case with CI/CD. Example of PowerShell script to build website in time zone with offset +7.

$utcNow = [System.DateTimeOffset]::UtcNow
$localTime = $utcNow.ToOffset([System.TimeSpan]::FromHours(7))
$localTimeString = $localTime.ToString('O', [System.Globalization.CultureInfo]::InvariantCulture)
$settings = "SiteDateTime=$localTimeString"
& wyam --setting $settings

Maybe the script can use be extended to work with NodaTime to use specific time zone data and deal with day-light saving time.

@daveaglick

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

I like this idea - it makes total sense to allow the site generation to seem like it's taking place at some time other than Now.

Are you going to use NodaTime throughout, or at least DataTimeOffset?

NodaTime is a definite no. I try to keep the dependencies in the core libraries to a bare minimum. It's probably a good idea to transition all DateTime uses to DateTimeOffset - I've added this as a separate issue to Statiq here.

Actually this step is "no change". Currently Published metadata value is entered in format yyyy-MM-dd. So it contains only date information, but no time or time zone.

Agreed - I don't want authors to have to specify a time zone.

Other option would be to extend the metadata value

If I recall it does a TryParse on the value, so more complex time strings should work today (though since it's not parsing into a DateTimeOffset right now there might be comparison oddness).

The rest of @duracellko proposal looks great. I'll get this into the first Statiq release.

@duracellko

This comment has been minimized.

Copy link
Author

commented Aug 13, 2019

I am back from holidays. I will try to look at it and make a PR on weekend.

@daveaglick

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

@duracellko I certainly don’t want to discourage you from contributing! That said, a PR to the Wyam repo has a very low chance of being merged right now. Statiq is far enough along that PRs here won’t port that well and I’m not planning another Wyam release unless an urgent patch is needed.

Hold on to the idea for a few weeks while Statiq finishes up and then we’ll revisit in that codebase to make sure this makes it into the initial release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.