Query -- Changing creation date in a human actionable way? -- #creationDate

[@TiddlyTweeter]

I want to manipulate creation times so that filters will work to produce a correct date ordering for a CV via filters in the simplest fashion.

This means editing the creation field so the date matches the actual CV entry dates. 

How can I do that in way I'm not having to figure out a very long number? 

All I need is to change date, times can be left. I wonder if anyone made a tool  to enable this?

Any help appreciated.

Josiah

[@TiddlyTweeter]

Repeat for email.

On Monday, 8 April 2019 09:58:27 UTC+2, @TiddlyTweeter wrote:

I want to manipulate creation times so that filters will work to produce a correct date ordering for a CV via filters in the simplest fashion.

This means editing the creation field so the date matches the actual CV date. 

[PMario]

On Monday, April 8, 2019 at 9:58:27 AM UTC+2, @TiddlyTweeter wrote:

I want to manipulate creation times so that filters will work to produce a correct date ordering for a CV via filters in the simplest fashion.

hmmm, IMO a very bad idea. ... You should never touch the tiddler "created" date. ... If you really need to handle it in a special way, use a custom field.

The main problem is: If anyone starts to modify created or creator, others can't rely on it. So it's useless. .. If it's useless, we should completely remove it.

Eg: federation.

 - I write something with date: 2019-04-09 in my "space"

 - You respond to it on 2019-04-10 in your space

 - Now I change the date to 2019-04-11

If we create a combined view, your answer will be listed earlier. ... Do you really want that?

have fun!

mario

[TonyM]

Josiah,

I concur with mario. Both created and modified can be used to drive a number of processes and systems and should not be played with as it compromises the wiki.

Using a date picker or allowing time stamping a value into another date field can make this so easy. You can even add the additional date field creation to your new tiddler process, or initially do a bulk copy of created date to your new date field to get started. 

For example, My new journal process adds a new-journal-date to every journal tiddler to allow any title format to be used, but there is a always a reliable date field. If I want to enter an entry for a past date I change the title and new-journal-date not the created date. To keep the information that tells me that journal entry was created before or after the date it relates to is potentially helpful at a future point in time. For example I could determine how often I get to make a journal entry on the actual date, if created date = journal-date, or pre-dated and post dated entries. 

It is not worth the potential loss to damage the integrity of the created date.

• Look at my use of edit-text widget here https://groups.google.com/forum/?hl=en#!searchin/tiddlywiki/html$20types%7Csort:date/tiddlywiki/4aCyZ3FAq9U/todMTtt-AgAJ
• If you use a non standard tiddlywiki date you will find the recently published date macro by SS helpful see the end of the thread for updates https://groups.google.com/forum/?hl=en#!topic/tiddlywiki/_bbDpiiReic
• or get http://kixam.github.io/TW5-datePicker/ 
• or make a button that uses the now macro to set a field to now and use the full serial number date.
• Or add an action to a new tiddler button to create your date field

Regards

Tony

[@TiddlyTweeter]

Ciao cari TonyM & Pmario

In most ways I agree with you.

The use case is simply doing it once for singular projects I define before end-user gets them. It deals with legacy. Further additions are contemporary.

The main issue is doing it reliably. Not so easy. And on that I fully agree with you fully.

But IN PRINCIPLE never ever changing creation date seems a tad OTT.

Best wishes

Josiah

[Mark S.]

On Tuesday, April 9, 2019 at 9:25:38 AM UTC-7, @TiddlyTweeter wrote:

But IN PRINCIPAL never ever changing creation date seems a tad OTT.

I agree. The creation date field takes up at least 27 characters of space (JSON isn't a compact way of storing info). It makes sense to use it however you need it to work, and having it match the actual day a journal was created, for instance, makes sense. That said, creating that accurate date stamp might be tricky. There was a recent post about using dates in 2019-04-09 format, and I think it has all the code you would need to set up your dates correctly.

-- Mark

[@TiddlyTweeter]

Ciao Mark S.

That was my feeling. Better manipulate the inbuilt system as primary if it gives all you need. Seems lightweight and doable.

The input side was what my question was about. To do it in a reliable way--because I see issues if you don't change the dates accurately.

Thanks for affirming I'm not entirely mad on this!

Best wishes

Josiah

[springer]

Reviving an old thread about timestamps here: 

Sometimes I turn timestamps off, to keep the "Recents" tab useful for students -- so they can see what's actually substantively new, without getting distracted by minor edits. (In TWC, I liked the ability to close an individual tiddler's edit session using some extra modification keystroke, so that the save registers as "minor" and not worthy of updating the modified timestamp.)

If I happen to create a tiddler in TW5 while timestamps are off, the tiddler ends up without a create date. Once I've created it, it seems TW5 won't even back-fill the create date to coincide with the first recognized modification date (once timestamps are back on). So the only way I've found to give it a create date is to clone it and delete the original. That works fine if I realize right away, but gives misleading results if I catch it significantly later.

I do see these reasons not to make these fields easily modifiable (as they were in TWC), but then there ought to be more options... 

Perhaps someone can easily tweak the timestamps toggle so that it affects modification timestamps but not creation timestamps? 

[Eric Shulman]

On Thursday, February 13, 2020 at 4:30:49 PM UTC-8, springer wrote:

If I happen to create a tiddler in TW5 while timestamps are off, the tiddler ends up without a create date. Once I've created it, it seems TW5 won't even back-fill the create date to coincide with the first recognized modification date (once timestamps are back on). So the only way I've found to give it a create date is to clone it and delete the original. That works fine if I realize right away, but gives misleading results if I catch it significantly later.

I do see these reasons not to make these fields easily modifiable (as they were in TWC), but then there ought to be more options...  

Here's a little trick to changing the "created" date on an existing tiddler:

1) edit the desired tiddler

2) in the "add a new field" controls, enter "created" in the "field name" input (even though the field already exists!)

3) in the corresponding "field value" input, enter the desired date using format "YYYYMMDDhhmmssxxx" (i.e., a 17 digit number)

notes:

* if you are only concerned with the date (but not the time), you can enter a value using "YYYYMMDD" and the remaining digits will default to zeros.

* the date number uses UTC time zone, not the local time zone.

enjoy,

-e

[TiddlyTweeter]

Ciao Eric

Very useful notes you wrote to springer!

I increasingly get interested in date handling in TW. Mainly because "created" can be used elegantly to solve a bunch of practical end-user issues.

For instance - "created" (once manipulated) can be used to identify things well (TV script year from past; real CV moments etc ...)

"Creation" is "foundational" in a naive, very useful, way. It makes immediate sense. Manipulating created date can be very useful.

If there is one thing I'd like do it would be to fully document creation date behavior. This is a good start, along with yesterday's comments by you and Mark S. on the absolute date range start (https://groups.google.com/d/msg/tiddlywiki/YaFzHXfjnFc/DjidjNfqAAAJ).

Best wishes

TT

[springer]

Thanks so much Eric. Though changing the create date could be manipulated for misleading purposes in certain shared-responsibility situations, it will be occasionally very helpful in cases like mine. 

Cheers!