Day of year as date handling mechanism

#1

Folks,

I am trying to open date handling ranges and maths up to a broader audience.

Background

We can use the day of year “0ddddd” (DOY) in both the now macro and date formats ($view widget and format operator) which allows us to quickly obtain the DOY for any date. If we prefixed this with the current year of the Form CCYY eg 2022 and can Zero fill the number eg 001 021 215 we end up with a sortable infinite (at least until 2100) serial date. We need only handle the change in year and 365/366 days.

To provide the tools to support his approach I want to find a way to easily do the following taking into account the number of days in any year;

  • Zero fill the DOY to three digits we can use the pad[3] operator
  • Convert a given CCYYNNN to a calendar date and reverse
  • Provide and add and subtract days that throws to new years

All these can be coded with current macros and widgets, perhaps with the exception of CCYYNNN to calendar date, but I am keen to see if we can get a robust solution or extend existing tools.

[Edited]

  • I think we need an additional form of ddddd with 0ddddd giving us the three digit day number with the pad[3] built in.
  • Examples include add N multiples of 7 to a CCYYNNN for N weeks time
  • Simple day ranges eg from one date to another add 20 days.
    • A year from now can just use the matching NNN and change the CCYY
    • If you want to set it to ± N months, quarters etc, you will need to use months and day of month etc…
TiddlyWiki resilience due to untyped fields
#2

I do not want to discourage you by any means, but from personal experience I know that date handling in wikitext is messy. Date handling in general is so full of edge cases that trying to implement a general solution is a lot of work, where one can never be sure that all bases really are covered.
For anything more advanced than going back/forward a few days, I started using @EricShulman’s ParseDate filters. Basing everything off the Unix epoch leverages all the work that has already been done to get in right in JavaScript / the browser / the OS. I’m hoping it’ll become part of the core someday, but for me Eric’s plugins are “core quality” and I don’t mind using them, even though I usually try to keep the number of installed plugins to a minimum.

Have a nice day
Yaisog

#3

Thanks @Yaisog

  • This is actually my motivation. In most “get things done” wikis 95% of date manipulation is covered if we can add or subtract a number of days, typically less than 365 days, as long as they can handle the year change.
  • I agree the Unix epoch is a good approach, but again more complex than my proposed solution, for an end user with simple needs.
#4

I’m curious to see what comes out of it. Can only improve the current state of affairs…
If I were to do something like this with minimum time expense and maximum usefulness, I’d define a bunch of subfilters that are likely to be needed, e.g.

\define tomorrow() [<now>unixtime[]add[86400000]unixtime[YYYY0MM0DD0000000000]]

Any number of days in the past or future is basically the same, just needs a different add amount.
Something like “next Monday” is a bit trickier, but still just a one-liner:

\define next-monday() [<now>unixtime[]] [<now dddd>negate[]add[8]multiply[86400000]] +[sum[]unixtime[YYYY0MM0DD0000000000]]

Using unix epoch you don’t have to worry about month or year rollovers.
Now, months get ugly. Unix time doesn’t help here, since you don’t know how much time to add without making lists. Might as well remain in wikitext. This will return the first day of next month:

\define next-month() [<now 0MM>add[1]divide[13]floor[]add<now YYYY>] [<now 0MM>add[1]remainder[12]] [[01000000000]] +[join[]]

Luckily, you’ll only have to account for year rollover here.
Years are probably also better handled directly in wikitext. Fortunately, there is no rollover at all.

You could also just set respective variables with these filters and use them for (number) comparison against a TW date field.

Have a nice day
Yaisog

PS: Returning the difference between two dates in months, weeks, days, etc. is one of the rare occasions where I resorted to JavaScript because wikitext became too unwieldy…

#5

If you need a sortable date use YYYY.0MM.0DD and you are good to go forever. No special handling needed.

2 Likes
#6

Mario,

Being sortable is one of its qualities the other is it is simple to add or subtract days, and make a macro to deal with year changes.

The only weakness is there is currently no way I can see to go from CCYYddddd to a CCYY0MM0DD or similar date although this is most likely possible within the existing code, or at least introduced at the same time as moving Erics unix-epoch into the core.

  • It makes sense to me to allow users/designers a direct way to add N days to a date especially we can already get “CCYY0ddddd” {{{ [[20220102]format:date[YYYY0ddddd]] }}}
    • I just confirmed the 0ddddd is working in this example

I am writing a proof of concept now, ignoring leap years