[TW5] UTC Problems

[TonyM]

Folks,

I know this has being discussed previously but I could not see a clear answer.

On My Wikis created and Modified dates reflect my local PC or Browser settings.

TiddlyWiki.com says To avoid problems arising from differences of time zone, TiddlyWiki always uses UTC.

If this is so where do we set that I am in +11 zone when displaying Dates?

However I use 

Date Picker Version 0.5.2 $:/plugins/kixam/datepicker

and

Moment.JS version 2.18.1  $:/plugins/kixam/moment

and especially when I use <$edit-date> 

When its 3pm here the time stamp is Tomorrow at 2am or +11 hours

So these tools are using my computers time as UTC and Adding 11 hours

The Are not using UTC and showing time with +11

Some help would be appreciated.

Tony

[PMario]

On Thursday, March 15, 2018 at 5:13:51 AM UTC+1, TonyM wrote:

I know this has being discussed previously but I could not see a clear answer.

On My Wikis created and Modified dates reflect my local PC or Browser settings.

TiddlyWiki.com says To avoid problems arising from differences of time zone, TiddlyWiki always uses UTC.

That's right.
 

If this is so where do we set that I am in +11 zone when displaying Dates?

That's part of your computer settings. The browser and js use these settings.
Does empty.html set modified and created in the right way? If yes, it's not a TW issue
 

However I use 

Date Picker Version 0.5.2 $:/plugins/kixam/datepicker

and

Moment.JS version 2.18.1  $:/plugins/kixam/moment

and especially when I use <$edit-date> 

When its 3pm here the time stamp is Tomorrow at 2am or +11 hours

So these tools are using my computers time as UTC and Adding 11 hours

The Are not using UTC and showing time with +11

To me it seems to be a plugin problem. atm.

-mario

[PMario]

Hi,

What happens,

 - if you go to http://kixam.github.io/TW5-datePicker/#Demonstration 
 - open the tiddler and copy the content to a new tiddler
 - done

The time shown in the example should be the time of your computer watch.
created field shown in the info panel should be different.

-m

[PMario]

edited version

[TonyM]

Mario,

This tested OK. Both on http://kixam.github.io/TW5-datePicker/#Demonstration  

and in my Wiki with the apparent problem.

Too late today for me to work this out but I notice when I set a future date it carries today's time with the date. This may have something to do with it.

I also wonder why 

{{!!created}} gives me a formatted date Fri Mar 16 2018 22:26:55 GMT+1100 (AUS Eastern Daylight Time)

and 

{{!!item-started}} containing 20180315223215000 shows 20180315223215000 <this is what I expected>

Perhaps when I use date picker on  20180315223215000 it goes wrong somehow?

Regards

Tony

[PMario]

On Thursday, March 15, 2018 at 12:39:08 PM UTC+1, TonyM wrote:

I also wonder why 

{{!!created}} gives me a formatted date Fri Mar 16 2018 22:26:55 GMT+1100 (AUS Eastern Daylight Time)

created is a special TW field, which internally is treated as a "date-field"..

What does the "created" field show in the info panel? .. It should be 11 hours off. ... That's expected.

- m

[Ste Wilson]

I think the simplest work around is to movebto the uk...

[TonyM]

Ste,

I was recently at the same latitude as the UK in Paris for the last few weeks, Moving to the UK is not so simple when you take the weather into account. Vs Sydney

Nevertheless, I would love to live in the UK for an Extended period but not to solve this timezone problem.

Regards

Tony

[TonyM]

Mario,

The Info panel shows the GMT version of the time as -11 from my local expected.

I had assumed sticking compliet date values in a field made it a date field.

Is there a guide to handing custom date fields in tiddlywiki somewhere?

I am 90% the way through building a Tiddler Disposition tool that uses a set of date fields to make the life cycle of different tiddlers easy.

I am not sure how to proceed in light of the discovery that I am not sure how to get fields treated as date fields, and to get edit-date fields to be stored as UTC and manage the time part of this select date.

Thanks for your help

Regards

Tony

[Mark S.]

I think most of your documentation is stored in the documentation tiddlers for the  Now Macro, the ViewWidget, and DateFormat.

It seems like the View widget should be able to display the correct date on any field containing a UTC-based date.

But if your plugins are creating incompatible dates, then you probably either have to rewrite the plugins or make a conversion utility.

-- Mark

[Ste Wilson]

Hi Tony
I appreciate it's not actually an easy thing to do. I was joking... ;)

[PMario]

On Thursday, March 15, 2018 at 11:40:34 PM UTC+1, TonyM wrote:

The Info panel shows the GMT version of the time as -11 from my local expected.

ok
 

I had assumed sticking compliet date values in a field made it a date field.

nope. There are "special" field modules registered at startup.
 

Is there a guide to handing custom date fields in tiddlywiki somewhere?

no. Every special field has a core module, defined at boot time. created, modified, tags, list, color

Those functions are not generalized atm. .. They "kind of invisible" for standard users.

It is possible to create a plugin, that adds special handling for other fields. ... But I'm not 100% sure, if there are side effects. .. I didn't use this mechanism yet.
 

I am 90% the way through building a Tiddler Disposition tool that uses a set of date fields to make the life cycle of different tiddlers easy.

I am not sure how to proceed in light of the discovery that I am not sure how to get fields treated as date fields, and to get edit-date fields to be stored as UTC and manage the time part of this select date.

I can point you to the source code, that's responsible. ... this is deep-diving ...

code: https://github.com/Jermolene/TiddlyWiki5/blob/master/boot/boot.js#L866
Init: https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/startup/load-modules.js#L27
usage: https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/tiddler.js#L34
usage: https://github.com/Jermolene/TiddlyWiki5/blob/master/boot/boot.js#L844

If you do a global search for: .fieldModules  ..you'll get the info how color field is used with edit widget. ...

I'm not sure if this helps.

-mario

[TonyM]

Mario,

Thanks this is very helpful. However it is a little disappointing to learn this.

Without "special" field modules registered at startup we should have an easy to use date field mechanism, after all we would expect this to be a common requirement for tiddlers, such as due, review or expiry dates etc..

Perhaps this already exists (as I am a long way to completing this), just that it is different to the Created and Modified date handling, that is ok, I just need to understand this, and you have being very helpful. I expect to find lots of information in your suggestions and Marks S.

Regards

Tony

[PMario]

On Friday, March 16, 2018 at 2:37:54 AM UTC+1, TonyM wrote:

...

Without "special" field modules registered at startup we should have an easy to use date field mechanism,

 

after all we would expect this to be a common requirement for tiddlers, such as due, review or expiry dates etc..

As a developer you'll never know, how your users will use your software. Most of the time in a completely different way as you expected it. ...

So because you as a user need "your own special handling" for the problem you want to solve at the moment, you expect it, to be there and it should be easy to use.
That's ok.

On the other hand, as created, modified and so on where developed, Jeremy implemented just enough code, to solve the problem he wanted to solve at this point in time.
The implementation is done in a "relatively" modular way, so it can be extended. ... BUT ... The code hasn't been cleaned up, since then.
So the implementation is not as polished as other functions in TW. ...

That's the status quo, atm, because nobody made an implementation, that is "generic enough" to be easily used. ...

There have been some discussions at github about "typed fields"

see issue: lookup-fields (or relationship-fields) #1324 a relatively long discussion, and
the condensed version: typed fields #1331

So it's not only the type of a field, that is important. .. eg: If we have a type: date, we also may want to have UI to view/edit the: date, checkboxes, option fields, tag-like fields ... as described in the issues. So it will be easy to be used ;)

have fun!
mario

[TonyM]

Mario,

I understand the developer perspective, because I was one before, I hope to be again. 

I hope I did not cause offence. I have no desire for special handling, for my current problems, my own solutions are usually systematic and with the future for all of us in mind. Perhaps this has come form my design and developer experience. In this use case I am simply trying to have additional date fields, and the way created and Modified dates have being implemented are not so transparent to me. And of course the apparent UTC Problem.

When I speak of a disappointment, or need to resolve/extend TiddlyWiki I speak as "We" and are not criticising, but contributing.

In fact I have given this a lot of thought, with a view to maximising utility, In many ways I am getting close to designing a solution myself, inside the constraints of the current version. Unfortunately I have YET not learned what I need to, to contribute in GitHub, and developer circles. This may be the issue where I start using Git-Hub.

My Own First plugin - that still requires polishing, MyMenus leverages the Wikification of values in fields to create an extremely extensible solution, and I hope will result in a treasure trove of "Code" snipits.

I for one are all about generic, non specific, open and reusable solutions. So lets see If I can contribute, perhaps even to "make an implementation, that is "generic enough" to be easily used".

Possibly my greatest fear is not having the ear of those who influence the core, and the time to speak in my less than trained words about my ideas, to such people (perhaps like yourself).

You may have seen my discussions in relation to making fields first class citizens, like tags are, when a Tag can also be a tiddler, I am already allowing fields to be represented by a tiddler, or field-tiddlers to be created that support many of the features your linked to in "Typed Fields" and "lookup fields" do. I expect these to be complementary, but personally I am not so sure typed fields are essential. I would be concerned if fields became stricter in definition, since their openness is already a powerful feature I am exploiting.

The Lookup idea that Tobias starts the thread with is an important idea, That my solutions is endeavouring to solve along with others, the related field-tiddler can store one or more lookup "filter(s)" that that can be used to populate that field where it is used in tiddlers along with other intelligence. I am also trying to get the field tiddler to include macros, lists, create, edit and even related fields tools and even CSS data. 

All I hope is a little tweeking to allow to make such field manipulation a little user friendly.

Thanks for your background and inside knowledge, it helps me learn.

Regards

Tony

[PMario]

On Friday, March 16, 2018 at 1:27:35 PM UTC+1, TonyM wrote:

...

I hope I did not cause offence.

Not at all. ... I just wanted to shed a bit of light from a different perspective.
-m

[PMario]

On Friday, March 16, 2018 at 1:27:35 PM UTC+1, TonyM wrote:

...

Possibly my greatest fear is not having the ear of those who influence the core, and the time to speak in my less than trained words about my ideas, to such people (perhaps like yourself).

I think your contributions are great. ... An you have the dev's ears ;) ...
 

You may have seen my discussions in relation to making fields first class citizens, like tags are, when a Tag can also be a tiddler, I am already allowing fields to be represented by a tiddler, or field-tiddlers to be created that support many of the features your linked to in "Typed Fields" and "lookup fields" do. I expect these to be complementary, but personally I am not so sure typed fields are essential. I would be concerned if fields became stricter in definition, since their openness is already a powerful feature I am exploiting.

I think, you stumbled upon a "known" problem, where we don't have a satisfying solution atm.

There have been several threads here in the group, where users wanted to have a "second" tag-like field. ... and the ActionListopsWidget is only a partial solution.

-m

[TonyM]

Thanks Mario,

Personally I feel the idea of a  "second" tag-like field is of some importance but separate from improved field handling. I was part of that desire for additional tag like fields and for me it was so I could use tags for found relationships and the alternative tags for the logic/data model I built into a Wiki such subject areas, projects, references, keywords etc... as you say the list ops widget goes a long way to enabling this. The Gap we still face for  tag-like fields, date fields and other advanced field handling is I believe very small, we just need a few features to make it easier to display, edit and create fields.

Thanks for the discussion

Tony

[Jed Carty]

To partially back up what TonyM said, I did make the GenTags plugin that lets any field act like a tags field. http://ooktech.com/jed/ExampleWikis/GenericTagFields/

I believe that the way to go with this is not to make specific fields act in a certain way but to make it so that any field can be used as a tags or date (or other) kind of field. Improving field handling removes the need for a second tags field because it would allow you to use any field as a tags field. Unfortunately we can't do this for the existing date and tags fields because of backwards compatibility issues but I think moving forward this is the way to go for any new features. 

[TonyM]

Jed,

Thanks for that GenTags plugin. I have being playing With Gen Tags and think it is great. 

To me its key use case is introducing subjects, categories, and other organising "tags" that allow their own set of values, such that they are not to be mixed with the other tags which are used for a range of purposes.

This is basically advanced field handling however It maintains a standard field, that listops can act against.

I do not think we need to be concerned with the existing date and tags fields because they are in a sense "core" functionality. I have already manipulated them without too much complexity such as letting modified be set to created date, but there is value in created being an immutable field. With additional tools such as GenTags we need not change the existing tags field because it too represents a minimum (but very powerful) default organising principal including driving settings and the UI. Thus I feel there is no backwards compatibility problems if we leave existing "system" fields alone while supporting new field handling tools.

Please forgive me, however we all try to stand on the shoulders of giants, in this case your GenTags makes you a giant, however I can see a need for a possible enhancement or two. I will describe them here should you wish to consider implementing them.

Tags as Tiddlers. 

As you know a tag pill allows us to click on the tag name and create a tiddler by that name. I tend to use this to document what the tag represents, and sometimes I provide the lists to interrogate which tiddlers are so tagged in that tiddler.

It would be nice if GenTags tagpill popup title would show if there was a tiddler or it was missing (italics) like in regular tags, and clicking on it would create a tiddler. I think this will only be a matter of changing this title into a link.

Open all items so Tagged

I use the open all plugin $:/plugins/ajh/openall which presents an Icon in the Tagpill popup that allows me to open all tiddlers tagged with that tag. Of course it is not aware of GenTags and does not work for them.

It would be great if we could also do this in the GenTags popup, it is only a matter of issuing an open tiddler message for all tiddlers already listed in the tagpill list. This would allow all tiddlers in the GenTags set to be opened at once.

Hide Edit GenTag in tiddlers not containing the defined fields

I have being looking through the code to see if I could stop the Edit GenTags showing in tiddlers in edit mode, until the relevant field exists. This would allow most tiddlers not to see my extra tag field exists, and save valuable screen real estate, until the field in question exist in the tiddler. For example my additional tags field called subject will not appear in edit mode until I create the field subject in a give tiddler. I would use a menu item using MyMenus plugin to create the subject field, and thus subsequently display the Subject tags.

With the Current Plugin, and possibly with the above enhancements I will publish a use case and demonstration in the forums. I want to support and Promote this long sought after tool which I believe has being neglected.

I also expect the structure of the GenTags solution could be co-opted to support other advanced field tools as discussed previously. It is an elegant solution.

Thanks again for your work.

Tony

[TonyM]

Jed,

I have found an answer for the following item

Hide Edit GenTag in tiddlers not containing the defined fields

Just hide in view and edit mode and add back a filtered invocation of 

<<TagLikeList fieldName label showEmpty wikify>>




and in the edit template

<<EditTagLikeList fieldName label wikify>>

Thanks Tony

[Jed Carty]

The tags as tiddlers part you describe is also part of the GenTags plugin, the times when it doesn't show as a link is because you have it set to wikify the contents of the tag name which lets you put whatever you want in the tag. I could change it so that whatever is there is always treated as a link when you click on it but it may break some of the other wikification parts.

I can look at adding an 'open all' button to the tags when I work on it again.

[TonyM]

Thanks jed

Of course I am only refering to the tag pill popup to link to the tiddler of the twg.

I am intregued by the wikify option and Will explore that.

Thanks
Tony

[Mohammad]

Hi

On Thursday, March 15, 2018 at 7:43:51 AM UTC+3:30, TonyM wrote:

Folks,

I know this has being discussed previously but I could not see a clear answer.

On My Wikis created and Modified dates reflect my local PC or Browser settings.

TiddlyWiki.com says To avoid problems arising from differences of time zone, TiddlyWiki always uses UTC.

If this is so where do we set that I am in +11 zone when displaying Dates?

However I use 

Date Picker Version 0.5.2 $:/plugins/kixam/datepicker

Where can I find more infor regarding these plugins? Do you know publishe/author: kixam?

 

and

Moment.JS version 2.18.1  $:/plugins/kixam/moment

Does any boy knows how to create a similar plugin but using moment-jalali instead on moment.js?

https://github.com/jalaali/moment-jalaali

The final purpose is to have othet calendar system in Tiddlywiki like Jalali.

--Mohammad

[Mohammad]

I found the author and source of moment.js plugin:

The github repo is here: https://github.com/kixam/TW5-moment.js

belong to kixam. he/she has contributed to TW for while (Jul 2015 - Jul 2016) and disappeared!

--Mohammad

[Mark S.]

Is there any known algorithm between the Gregorian and the other calendars ?

I did some searching and reading, and it kind of seemed like even experts hadn't worked it out. But maybe I was running down the wrong rabbit hole?

The formulae I found came with the caveat that they might be a day or two off!

Recall that TW's internal dates are only good for about 200 years back.

One workaround might be to use a data dictionary with all the dates for some desired period of time pre-translated between systems.

[TonyM]

Mark and Mohammad

This thread is titled utc which of course is time rather than dates, this difference fades over time and you are only concerned with the date.

Remember even if tw5 does not "support" a given date you can store anything in a field. I would expect many have needed conversions in the past and expect there are precalculated calendar conversions available in tables if not conversion ranges.

My thought is looking for conversion algorithiums rather than reference tables is posibily unnecessarily complex. Partial algorithium could be used to reduce the size of any table.

I say this based on the fact most calendars are historical not mathematical often need corrections to map to the heavens. I am sure archeologists, historians and anthropologists have addressed this already.

Regards
Tony

[Mohammad]

Hi Mark,

On Monday, April 13, 2020 at 2:25:46 AM UTC+4:30, Mark S. wrote:

Is there any known algorithm between the Gregorian and the other calendars ?

Yes, there are! 

I did some searching and reading, and it kind of seemed like even experts hadn't worked it out. But maybe I was running down the wrong rabbit hole?

As an example in the case I am looking there is very good JS code, please have a look here

https://github.com/jalaali/moment-jalaali

https://www.npmjs.com/package/moment-jalaali

It seems moment-jalali acts like a plugin or submodule for moment.js

 

The formulae I found came with the caveat that they might be a day or two off!

Recall that TW's internal dates are only good for about 200 years back.

One workaround might be to use a data dictionary with all the dates for some desired period of time pre-translated between systems.

So, you propose a Tiddlywiki way! If so, I should find first the formula behind it ! 

[Mohammad]

Thanks Tony,

 I did some Google search and it seems there good JS code! 

If a simple code in TW itself can do the job that would be great!

--Mohammad

@Mark and  Tony

I start a new thread for this topic

[TiddlyTweeter]

Mark S. wrote:

Is there any known algorithm between the Gregorian and the other calendars ?

I did some searching and reading, and it kind of seemed like even experts hadn't worked it out.

Ciao Mark

I am pretty sure somewhere you find converters for Julian <=>  Gregorian.

But ... complexities arise for historians that ...

1 - ... different societies transferred from one to the other at different dates. And the later the transfer date the greater the number of days that get destroyed. So solutions would need to account for country variations. That could get a little complicated ...

2 - ... a difficult problems in history is if, say, you wanted to find a day in England and then find the French equivalent where France converted and Britain hadn't. 

However ...

3 - When quoting dates from historical documents (for a single country) it is not often necessary to calculate the date as the document itself bears the socially recognised date.

4 - Also, in many cases, during the transition period between calendar systems, both the old and new dates were recorded.

Best wishes

TT

 

[PMario]

On Monday, April 13, 2020 at 7:32:06 AM UTC+2, Mohammad wrote:

Hi Mark,

On Monday, April 13, 2020 at 2:25:46 AM UTC+4:30, Mark S. wrote:

Is there any known algorithm between the Gregorian and the other calendars ?

Yes, there are! 

I did some searching and reading, and it kind of seemed like even experts hadn't worked it out. But maybe I was running down the wrong rabbit hole?

As an example in the case I am looking there is very good JS code, please have a look here

https://github.com/jalaali/moment-jalaali

https://www.npmjs.com/package/moment-jalaali

moment.js  probably isn't the best choice. It's big and slow. 

There seem to be some built in functions too. ... But need to investigate: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl

-m

[Mohammad]

 Mario!

On Monday, April 13, 2020 at 6:22:36 PM UTC+4:30, PMario wrote:

On Monday, April 13, 2020 at 7:32:06 AM UTC+2, Mohammad wrote:

Hi Mark,

On Monday, April 13, 2020 at 2:25:46 AM UTC+4:30, Mark S. wrote:

Is there any known algorithm between the Gregorian and the other calendars ?

Yes, there are! 

I did some searching and reading, and it kind of seemed like even experts hadn't worked it out. But maybe I was running down the wrong rabbit hole?

As an example in the case I am looking there is very good JS code, please have a look here

https://github.com/jalaali/moment-jalaali

https://www.npmjs.com/package/moment-jalaali

moment.js  probably isn't the best choice. It's big and slow. 

Many thanks for the hints