I think you're talking about using your own dates, in the short form e.g.
20190216. Because you don't use all the digits of the time, TW pads the
number and assumes that it is 20190216000000000 or midnight GMT. Since at
midnight GMT, it's still the 15th on days west of timezone GMT, the days
operator doesn't show it.
A trick, which I haven't thoroughly tested, is to add "9" after the bespoke
date:
201902169
Whether that causes trouble on the 17th, I don't know.
-- Mark
On Friday, February 15, 2019 at 9:38:33 PM UTC-8, Hubert wrote:
>
> Hello,
>
> I'm aware this topic was raised many times before, so my apologies for the
> sprawl.
>
> TiddlyWiki treats all dates in fields as UTC, which makes sense. We have
> the view widget to 'translate' that UTC date to our local time (depending
> on time zone, daylight saving time offset etc). All good so far.
>
> However, the days filter operator by definition skips any time portion of
> a date field and only evaluates its date portion. At the same time, the
> days operator still treats date fields as UTC, which results in a full day
> negative offset of the interpreted date in timezones east of GMT.
>
> To illustrate my point:
>
> <$list filter="[all[tiddlers]tag[task]days:date[0]]">
> {{!!title}}<br>
> </$list>
>
> This will list all tasks that have today's date in its date field. So, on
> 16 February 2019, all tasks dated 20190216 will be listed by the above list
> filter, provided that your timezone is GMT or ahead (Asia, Australia etc).
> In timezones behind GMT (The USA, South & North America, etc), the filter
> will not list any 20190216 tasks on 16 February 2019, because the days
> operator has offset the UTC date of 20190216 by whatever number of hours
> behind the midnight of 20190216 that match the relative UTC offset of that
> timezone. This means that if you're in, say, New York, 20190216 will be
> offset from UTC by 5 hours and result in 201902151900 and the date is now
> interpreted as 20190215 (time is skipped), so essentially 1 full day.
>
> As far as I'm aware and if my understanding is correct, there's no way to
> work around this behaviour using the days operator but I would still like
> to hear about your ideas.
>
> What I'd like to suggest as well is that the date operator only works on
> full days and doesn't produce a negative offset from UTC in timezones east
> of Greenwich (the negative offset will always amount to 1 full day, because
> time is ignored by this operator). If we're working with full days I don't
> believe we should need to factor in any time offsets.
>
> I understand the design principle behind interpreting all date fields as
> UTC and I'm in favour of it, when it comes to time. But I also think that
> using the days filter operator may result in unexpected behaviour with no
> workable or easy workaround if the local time is behind GMT.
>
> I'd be happy to hear about your thoughts or suggestions to work around
> this problem.
>
> Thank you,
> Hubert
>
>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to tiddlywiki+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywiki@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/683ec051-b457-4318-a5fb-6bbf9ecd56ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
