Calendate

[New Tobin Paradigm]

Just an aside, while it sucks there is an issue currently, this cooperation is indeed inspiring to watch. Makes me feel pretty good.

[back0rifize]

Me too, New Tobin Paradigm, me too .

[coffeebreak]

do you use a x86 or x64 Pale Moon?

Using Pale Moon 28.7.1, Win 7 x86.

x86 Pale Moon, because x86 OS. ;)

[...] -> Export - you'll get a "calendate.sqlite" file on your desktop; take this file and send it to me (or just attach it right in this topic)

calendate.zip

(547 Bytes) Downloaded 13 times

[back0rifize]

Thank you, coffeebreak! I don't now what could I do without you.
Things becomes more interesting, as it was before . I checked out the data in your backup, and... look, what we've got here:

What does it mean? It means, that your records was added to DB with a decrease for 1 day! Give me some time, I need to add a special test buttons to sing a swan song in this bug opera.

[back0rifize]

So, here is a test version of Calendate:

calendate-4.4._bugtest.xpi

(162.77 KiB) Downloaded 13 times

What's the point:

• in "Editor", there are 2 buttons now, called "Get U Date" and "Get F Date";
• I want you to press the "Get U Date" and create a 2 pics (from console and from alert), and then do the same operations with the "Get F Date", and attach both of them here.

First button gets unformatted date string, but the second converts it to a locale date. And if my thoughts are right, you'll get a different values, and differ will be in one day between each other.

Thank you!

[back0rifize]

Sorry, I've forgotten one more thing: I remake test build again and now it must show a real current date in the toolbar. Please, check it, if you can:

calendate-4.4._bugtest_toolbar_date.xpi

(162.78 KiB) Downloaded 18 times

As usual, pic, please ...

[back0rifize]

coffeebreak, pal, I know you hate me already, but... here's another version of test build:

calendate-4.4._bugtest_toolbar_date_comparison.xpi

(162.79 KiB) Downloaded 12 times

It sets two types of date format in the status bar. Well, you know what I want to ask you about, right ? Yes, create a pic of a status bar (and the pics of result on pressing buttons in "Editor" too).

[coffeebreak]

• in "Editor", there are 2 buttons now, called "Get U Date" and "Get F Date";
• I want you to press the "Get U Date" and create a 2 pics (from console and from alert), and then do the same operations with the "Get F Date", and attach both of them here.

First button gets unformatted date string, but the second converts it to a locale date. And if my thoughts are right, you'll get a different values, and differ will be in one day between each other.

Using calendate-4.4._bugtest_toolbar_date.xpi...

The status bar does indeed now show the correct date:

The U dates and F dates are the same, one day earlier than the date shown in the editor.

First event:

Gymn.

Editor.

U date alert.

U date console.

F date alert.

F date console.

[coffeebreak]

(Cont'd.)

Second event:

Hiking.

Editor.

U date alert.

U date console.

F date alert.

F date console.

[Moonchild]

Just an idea, but could it be you're making a calculation mistake in the extension when the time zone is GMT -hours instead of +hours?

[coffeebreak]

here's another version of test build

Late on this one, but here it is. Back0rifize, this will be my last go-round for a bit.

Using calendate-4.4._bugtest_toolbar_date_comparison.xpi...

The second date format in the status bar is a day early. Was it not this way for you too?

Did you change anything re U/F dates from the previous version?
In any case, the U date and F date are the same, as was previously posted: one day earlier than the date in the editor. (And the date in the editor is itself incorrect as to the event date, early by a day.)

Screenshots for one event:

Editor.

U date alert.

U date console.

F date alert.

F date console.

I'll also mention (forgot earlier) that the date in the tooltip shown when you hover on the toolbar button is a day earlier than the real date:

calendate-button-tooltip.png (11.31 KiB) Viewed 2064 times

[back0rifize]

coffeebreak, in relation to you, let me quote Vangelis's phrase from this post: "you are worth your weight in gold" !

Moonchild, I was expecting you to come in this topic .

Take a look what we've got here: absolutely all alerts shows incorrect dates, BUT! console results without a .toLocaleDateString() method shows correct dates in both cases.

Here's the code of "Get U Date":

Code: Select all

var swanU =
{
	song : function()
	{
		var grabDateField = new Date(document.getElementById('calenDate-datepicker').value);
		alert(grabDateField);
		console.log(grabDateField);
	}
}

The value of 'calenDate-datepicker' is getting from this component:

calendate-datepicker_ID.png (4.23 KiB) Viewed 1931 times

In console, all unformatted strings has format "Date 2019-10-11T00:00:00.000Z" and "Date 2019-11-03T00:00:00.000Z" accordingly, which is fully comply to the dates set by coffeebreak:

console_U_1.png (1 KiB) Viewed 1936 times

console_U_2.png (1.03 KiB) Viewed 1936 times

Here's the code of "Get F Date":

Code: Select all

var swanF =
{
	song : function()
	{
		var grabDateField = new Date(document.getElementById('calenDate-datepicker').value);
		var F = grabDateField.toLocaleDateString();
		alert(F);
		console.log(F);
	}
}

Now, both consoles shows incorrect dates, when .toLocaleDateString() is using:

console_F_1.png (595 Bytes) Viewed 1936 times

console_F_2.png (593 Bytes) Viewed 1936 times

As one good man told me once upon a time: "Trust no alerts, but to console!" - and he was goddamn right; now I know, why.

The same thing happens in the status bar panel. Here's the code that I was using here (and as you can see, I don't calculate any GMT at all - neither here, nor in other blocks of code):

Code: Select all

// Getting formatted date

var bar = document.getElementById('calenDate-statusbarpanel-date');
var button = document.getElementById('calenDate-button');

var date = new Date();
var month = ('0' + (date.getMonth() + 1)).slice(-2);
var day = ('0' + date.getDate()).slice(-2);
var set = date.getFullYear() + '-' + month + '-' + day;
date.setTime(Date.parse(set));

// Adding current date to statusbar panel

var Cc = Components.classes;
var prefs = Cc['@mozilla.org/preferences-service;1']
.getService(Components.interfaces.nsIPrefService)
.getBranch('extensions.calendate.');
var datebar = prefs.getBoolPref('datebar');

if (datebar)
{
	bar.removeAttribute('style');
	bar.setAttribute('label', set + '        ' + date.toLocaleDateString());
	bar.setAttribute('style', 'font-weight: bold');
}
else
{
	bar.setAttribute('style', 'display: none');
}
//... and so on ...

Take a look at this string:

Code: Select all

bar.setAttribute('label', set + '        ' + date.toLocaleDateString());

When .toLocaleDateString() is not using ("set" value), coffeebreak got the correct result:

Set.png (571 Bytes) Viewed 1936 times

But with using the .toLocaleDateString() ("date.toLocaleDateString()" value), coffeebreak got the incorrect result:

Date.png (636 Bytes) Viewed 1936 times

And so on, where .toLocaleDateString() is using through all the extension.

What about incorrect dates showing in all datepicker's fields: AFAIK, "datetimepicker" component uses .toLocaleDateString() method for final drawing date, which user sees. And that's why all dates in "datetimepicker" decrements for one day.

So, Moonchild, seems to me, the cause of all problems is in .toLocaleDateString() method? Or?.. Is it just me?.. Thank you!

[Moonchild]

You're making a calculation mistake (by setting the time giving a date without time or TZ).

Simple test, Scratchpad to the rescue:

Code: Select all

var date = new Date();
console.log(date);

var month = ('0' + (date.getMonth() + 1)).slice(-2);
var day = ('0' + date.getDate()).slice(-2);
var set = date.getFullYear() + '-' + month + '-' + day;
date.setTime(Date.parse(set));
console.log(date);

console.log(date.toLocaleDateString());

In my (and your, being Ru) time zone, (GMT+), this outputs correctly. If toLocaleDateString() was the problem, it should not, because then it would be consistently wrong everywhere.

The problem here is you are using:

Code: Select all

date.setTime(Date.parse(set));

When you have a positive offset, all is well: you're making the universal date, e.g. 2019-10-13T10:28:15.370Z into a date with zeroed time 2019-10-13T00:00:00.000Z (by not supplying a time or time zone to Date.parse()) and then converting it to local time (which is the same date in GMT+ zones)
When you have a negative offset of GMT, you are setting the time to 00:00:00 universal on the date you want, BUT that is the previous day (-1) there, so toLocaleDateString() returns the day -1.

(I'm also a bit confused why you are manually parsing the date output when you are just converting it right back into it. Don't you trust the universal date format? Wouldn't it be much simpler to just get the date and then feed it directly to date.toLocaleDateString() for the output you want?)

[back0rifize]

Thank you, Moonchild!

Now I changing my code to use it with the time zones (Scratchpad):

Code: Select all

var offset = new Date().getTimezoneOffset()*60*1000;
var zone = new Date();
var date = new Date(Date.parse(zone) + offset);
var month = ('0' + (date.getMonth() + 1)).slice(-2);
var day = ('0' + date.getDate()).slice(-2);
var set = date.getFullYear() + '-' + month + '-' + day;

console.log(date);
console.log(date.toLocaleDateString());

And with the offset binding, now there is nothing to worry about GMT or UTC. Or there is more elegant solution? This is what I've found today in trying to solute this situation.

If I understand your question about parsing right, the answer is: Calendate stores user's data in .sqlite file, and because of constant calls to the database, I have to do this manipulations. Date format, which is stores in DB, looks like "YYYY-MM-DD" (and DB has columns, stores YYYY, MM and DD separately), so that's why.

UPDATE: after some experiments, this idea seems to be sucks. Continue digging (and, yes, Moonchild, you was right: the problem is because of a "T00:00:00.000Z")...

[back0rifize]

Finally, seems to me, it's done. I've tested it within 2 days (with time zones (+/-) and even user-agent locale), so if someone (like coffeebreak, for example ) could test it and give me some kind of a feedback, I shall appreciate it a lot:

calendate-4.4_new.xpi

(162.6 KiB) Downloaded 18 times

Thank you!

[coffeebreak]

test it and give me some kind of a feedback ... calendate-4.4_new.xpi

It looks fine. Dates now display appropriately everywhere afaics.

A few additional points of feedback...

• In the list of event types, there's a typo in the word "Business".
  

• For recurring events, once the initial date has passed there is nothing in the Events List to show that it will recur (Monthly, Yearly), nor the date it will next occur. People might find it useful to have columns that show: 1) the frequency of occurence (called something like "Recurrence" or "Repetition" or "Repeats" or "To Repeat"); and 2) the next date of ocurrence, to change as appropriate over time (called something like "Next occurence").
• When a recurring event is created, the calendar shows that date highlighted for times that precede its creation even though it's not relevant for earlier times. (For example, an event created to start Nov 04 2019 and recur monthly highlights the 4th of the month for Jan-Oct 2019 as well.) For the sake of clutter reduction, is it possible to only have that date highlighted for the months (or years if relevant) from the point of the event's first occurence and forward?

PS: I notice the thread has been marked as "solved." But if you aim to use it as a running support thread for future questions about Calendate, perhaps it shouldn't be so marked. What do you think?

[New Tobin Paradigm]

Off-topic:
I love bussiness!

[back0rifize]

It looks fine. Dates now display appropriately everywhere afaics.

I'm glad to hear it at last !

In the list of event types, there's a typo in the word "Business".

Oh, this is my misprint; already fixed (it was the simplest thing to fix).

For recurring events, once the initial date has passed there is nothing in the Events List to show that it will recur (Monthly, Yearly), nor the date it will next occur. People might find it useful to have columns that show: 1) the frequency of occurence (called something like "Recurrence" or "Repetition" or "Repeats" or "To Repeat"); and 2) the next date of ocurrence, to change as appropriate over time (called something like "Next occurence").

Yes, it's a good feature, you're right. I thought about it too.
You know, the thing is that first versions of Calendate worked with a .txt file (as a database), and it was not so suitable to do some things. So when we switched to .sqlite format, we simply didn't think about this part of an UI. Did it out of habit. Bad habit.

When a recurring event is created, the calendar shows that date highlighted for times that precede its creation even though it's not relevant for earlier times. (For example, an event created to start Nov 04 2019 and recur monthly highlights the 4th of the month for Jan-Oct 2019 as well.) For the sake of clutter reduction, is it possible to only have that date highlighted for the months (or years if relevant) from the point of the event's first occurence and forward?

Yes, I do understand, what are you talking about. This glitch goes from version to version. It's because of an absent ability to set a year, from which event must be getting started to. And, if so, technically, logic works well: it repeats your event from month to month. Other words: all I need, as a dev, is to add the break points ("start" and "end"). And it stays in plans, and will be done in future (but not in coming release).

UPDATE: I think I've found a solution, but shall try it a lil' bit later ...

PS: I notice the thread has been marked as "solved." But if you aim to use it as a running support thread for future questions about Calendate, perhaps it shouldn't be so marked. What do you think?

And you're right again, and damn me, it was nothing more but accidentally button press. How to dismiss it - I don't now, unfortunately. If someone, who can do this, read this topic now - please, uncheck the "Topic is solved" mark.

Thank you, coffeebreak, as usual ! Shall continue working. Today/tomorrow I'll try to attach to this topic a new beta with some fixes you've asked to do.

I love bussiness!

Sounds like a "bus-in-ass" ...

[back0rifize]

Alright, here's a small update in attach. Done:

• fixed misprint;
• added "Repeat" column in List.

Special thanks to %username%, who dismarked this topic as "Solved" !

[coffeebreak]

calendate-4.5b_tree_biz_fix.xpi

Repeat column looks good. :)
(I had pictured the list would also tell the next date an event occurs, but looking at it now, it seems unnecessary, that info is pretty obvious.)