Extend Metadata 'date' to include hours/minute/seconds ?

[clojj]

There are probably good reasons, to just have the day as a reference. But maybe there are scenarios, where the time-of-day also is useful. For example, just for visualizing the 'timeline' of creating new zettels on one specific day (?)

Also, maybe there should be some documentation, why not modifying the date in metadata is an important concept (if it is..).
I recognize, that extending date to include the time also needs some effort for the timeline-queries, but maybe these could initially ignore time (?)

A zettelkasten user is of course free, to edit 'date' at any moment, and a user can also add dates in the body of the zettel-text (by convention)... I don't know yet what the zettelkasten philosophy is saying about these issues.

[srid]

The "date" field is for storing the creation date of the zettel. We can certainly add time to it.

Originally I just didn't bother with time, only because of the "date IDs" that neuron had by default before we switching to random hash IDs.

Timeline queries can use the full datetime, and they would finally be able to deal with zettels created on the same day.

[srid]

Actually I think we should deprecate "date", replacing it with a "created" field. This would be semantically less ambiguous.

EDIT: Might as well take this opportunity to use local timezone (UTC was used only to make date IDs consistent).

[clojj]

I got this far...

Using LocaTime automatically determined the correct TimeZone.
We probably should also determine the best formatting
is it "yyyy-mm-dd HH:MM" or "yyy-mm-dd at HH:MM" ..etc.
?

Development experience is great now ! bin/test runnning in the terminal gives imediate feedback... love it !

[clojj]

btw, yesterday I somehow (sorry can't remember exact steps) got a version "0.6.0.5" on my system
either from building the source with bin/test or bin/run (?)
or was it actually a 0.6.0.5 from master that got reverted to 0.6.0.4 today ?

[srid]

0.6.0.5 had a severe regression, so it had to be reverted. (I just up'ed ver to 0.6.0.6 to avoid confusion)

Development experience is great now ! bin/test runnning in the terminal gives imediate feedback... love it !

Awesome!

As for formatting, the one in your screenshot looks good to me at first glance (assuming time is optional), but I haven't explored other formats in detail.

[clojj]

As for formatting, the one in your screenshot looks good to me at first glance (assuming time is optional), but I haven't explored other formats in detail.

"time is optional" ...do you mean that there should be a setting/option for generating time with neuron new "..." ?

[srid]

I mean that both of the following should be supported in the Markdown file:

• created: 2020-07-23
• created: 2020-07-23T09:43

And neuron new may just generate the full datetime (the user can delete the time part from the generated file if they wish).

[clojj]

Hi, just finished refactoring and everything looked fine, but I realized that my changes included possibly some logic that still should remain strictly at "day" ....which is basically everything aroung this type (and more I guess ?)

data ZettelID
  = -- | Short Zettel ID encoding `Day` and a numeric index (on that day).
    ZettelDateID Day Int
  | -- | Arbitrary alphanumeric ID.
    ZettelCustomID Text
  deriving (Eq, Show, Ord, Generic)

So my question is: can you point out, where the "day" should still be used ? I think it is some logic not related to the meta-tag "date" (to be renamed "created" by my PR), correct ?

[srid]

can you point out, where the "day" should still be used ?

1. date IDs (neuron new --id-date) which exists for backwards compact only.
2. created: 2020-07-23 in zettel metdata (i..e, specifying date but not time), also to support date: ....

If that doesn't answer your question, perhaps you can open a draft PR and rephrase your question in the ctx of relevant code snippets?

[clojj]

so maybe I should revert everything but Meta.hs, and start again from there....
but any additional info is welcome !

[clojj]

If that doesn't answer your question, perhaps you can open a draft PR and rephrase your question in the ctx of relevant code snippets?

yep!

[clojj]

I will try to create the PR in the next few days (travelling at the mmt)
But I think I need a function Day -> LocalTime (time being set to 00:00)
...which I have trouble finding (you know a way to do this ?)

[srid]

Actually I think we should deprecate "date", replacing it with a "created" field. This would be semantically less ambiguous.

I'm not so sure about this anymore. By using "created" - we hardcode the semantic of it. However, over at srid.ca I use the date to mean "published date". Often I write a note, and wait a few days/ weeks before officially "publishing" it in the blog timeline. When I do, I change the date to the published date. So it is not really a date the note was created (which IME is rarely useful), but rather that date the note was finalized (for public).