has this been tested with non gregorian dates, for example jalali? what would the Persian language pack have to add to its pack to force jalali? Is it rtl aware?

Does this work with the folowing config options from the language xml

  <firstDay>0</firstDay>
    <weekEnd>0,6</weekEnd>

@brianteeman I hope so:
check layouts/joomla/form/field/calendar.php lines:190-191

      data-firstday="<?php echo JFactory::getLanguage()->getFirstDay(); ?>"
        data-weekend="<?php echo JFactory::getLanguage()->getWeekEnd(); ?>"

@infograf768 Not yet, (rtl is tested tho). As I said #707 has all the changes needed, so it should be fairly easy to do

Preview RTL:

@dgt41 Great work!

Sorry i didn't have time before to check your code you linked me, but next week i will dedicate time to test this, and give all possible feedback!

Just a first issue : missing blank space at the bottom when opened, when field is at the bottom of the page, and because of the white "shadow" top of the fixed status footer.

@JoomliC thanks! Seems I forgot to uncomment these lines: https://github.com/dgt41/joomla-cms/blob/02c9cef6b29f44eb8dba5a1077bfa3a8b81214d8/media/system/js/calendar-vanilla.js#L575-L578

@dgt41 uncommented corrects the position (picker at top), but the position is not correct relative to the form field.

There the result when click on "Calendar 4" button :

@JoomliC so my calculations are off. It seems I hit that often lately ?

@dgt41 IMO, maybe set its position to top, and bottom only if not enought space at top ? (could be easier to manage too ;-) )
z-index could be higher i think, to keep it over menu and fixed bottom.
Not time enough to check code this week-end, but will look at it with more attention next week ;-)

non bootstrap preview:

@infograf768 Jalali is almost ready:

@dgt41 great job!
I already have some notes , but first I will try some tests ?

@Fedik I think this is what you meant:

        // Get all the calendar fields
        var calendars = document.getElementsByClassName("field-calendar");

        // Loop to initialize them all
        for (index = 0, len = calendars.length; index < len; ++index) {
            JoomlaCalendar.setup(calendars[index]);
        }

Now sub-forms should be happy ?

@dgt41 yes, this looks better, thanks!

I have tested this item ✅ successfully on 44589ad

I have Tested successfully this issue

@dgt41 it looks like we have merge conflicts.

@tomartailored @zero-24 this PR is not yet for "validating" testing, but for first tests, feedback, and improvements ;-)

@dgt41 Just started some tests, and when set by default (no optional attributes) <field name="color" type="calendar" label="Calendar default"/>, you have the time picker, but when a date is selected and time set or not, the input contains only date (not possible to set time).
Maybe due to the default date format %Y-%m-%d to be changed to %Y-%m-%d %H:%M:%S here : https://github.com/joomla/joomla-cms/pull/11138/files#diff-b01d47e3fbe4a8e5fb4987f4df64b291R961

In the same time, a question:
Wouldn't it be easier to have an hidden input to save the date in UTC iso format, and to display the date in visible input depending of the format attribute and language ? (could make it easier to manage with Jalali calendar...) ?

@zero-24 these are unit tests that are failing

@JoomliC are you spying on my computer? ?
I mean I had same idea of setting a hidden field. Ok I worked on it a bit more and now this is a data-alt-value="xxxxx"

@JoomliC are you spying on my computer? ?

@dgt41 you didn't know i did ? ?
Good idea about the data-alt-value (i thought of the hidden input, as managing timezones, non-gregorian calendars, etc... is not easy in the input directly, as better to always save datetime in UTC iso format ;-) ).
And doing so would be an improvement of what is done today and will prevent many issues in the future ;-)

@dgt41
How would it work for non-Gregorian calendars as fa-IR (Jalali)?

Until now, some code is included in fa-IR.localise.php
class fa_IRDate extends JDate {
with a series of methods.

and the js files are overriden in media/fa-IR/js/
and installed correctly by the site language installer

<media destination="fa-IR">
        <filename>index.html</filename>
        <filename>js/index.html</filename>
        <filename>js/calendar-setup.js</filename>
        <filename>js/calendar.js</filename>
        <filename>js/calendar-setup-uncompressed.js</filename>
        <filename>js/calendar-uncompressed.js</filename>
    </media>

As their pack can be updated/installed on < joomla version in which this new feature would be merged, could we keep B/C?

I also remarked that although the calendar field is still in English when using fa-IR (vanilla.js may need an override), the dates displayed in articles back-end column and frontend info block are Jalali which means that some of the specific existing fa-IR code is still used.

@infograf768 I will provide a nice and way more simplified workflow for all the non-gregorian calendars. My idea was to have the calendar.js as abstract as possible to be able to cope with any calendar. The lines required for the fa-IR calendar are like 200 and that should be about any other non gregorian calendar (of course this needs to be an overridable file). This means that Hebrew, Hindi and all other strange calendars could be part of Joomla and that will be a great marketing point!
Please allow me to demonstrate the whole thing after this weekend, as it still needs to be refined...

PS: PHP side needs no override for any non-gregorian cal

This means that Hebrew, Hindi and all other strange calendars could be part of Joomla and that will be a great marketing point!

@dgt41 cc/ @infograf768 :
Exactly how i would see it! (and much more easier to maintain, and prevent errors). ?

About globalization of dates
Additional comment, about possible improvements, where translators would be a great help ;-)

1. Order for month/year
   In some language, year is displayed before month in a calendar type, eg. Most Asian languages (eg. Japanese 2016年1月 where year is displayed before month in this case.
   Idea: <monthBeforeYear>1</monthBeforeYear> attribute in language xml install

2. Usage of prefix/suffix/separator
   eg. Japanese 2016年1月 where usage of numerics for year and month with a fix suffix for each one

3. Nominative/genitive grammatical cases
   Month spelling difference in some language in nominative/genitive grammatical case, eg. Russian/Ukrainian : in calendar (JANUARY) the nominative case Cічень 2014 and in a full date display, usage of genitive spelling 16 січня 2014 р.
   So, what about new strings of translation for month when used in a nominative way (calendar picker) ? cc/ @infograf768 @MATsxm

Maybe some other cases to take into account...?

Note 1: for mac user, iCal is a good way to visualize globalization of dates in calendar header, by switching system language. ;-)

I think that a list of all date formats, depending on each culture currently supported by Joomla! could be a useful starting point to see how to improve globalization ?

Note 2: i've tried to propose a PR some time ago (when i started to contribute) but this one got no real success feedback. But this could help to see the logic, and maybe find a best way to manage the calendar picker in a i18n way ? (see for details: #2809)

Order for month/year

Will add a switch for that

Usage of prefix/suffix/separator

Will add the needed logic

Nominative/genitive grammatical cases

@JoomliC can you check if https://github.com/samsonjs/strftime is already supporting this, as I am gonna use it instead of the Date.print() custom function that misses a bunch of options

@infograf768 do you know if the date that is stored in the database for fa-IR is the converted to gregorian or is it the local, (can't check at the moment)

The date in the database is Unix format

@JoomliC So far I implemented only the first of the three points you mention above (year-month order of display). Before I go on and implement the other ones I would like some input from the translator team if this is something that will be approved so @infograf768 and @Bakual the ball is on your side ?.

The status is: calendar-vanilla.js is complete with all the hooks for the date-helper.js (this needs some serious clean up).
As an example I will provide the Persian calendar date-helper.js (for B/C also)

PS. If you check the files you'll see that I touched core.js to add a call to a function for exchanging values from a data attribute instead of recalculating the input value before form submission. I hope this doesn't break B/C is some bizarre way

Are there any objections on making the field readonly?

Are there any objections on making the field readonly?

then need to add 'Clear' button, and open the calendar also after click on the input ?

@Fedik I have already implemented the option to open on click in the input (but needs the button hidden, probably I should change that). I guess clear should be there only for non required fields, doable, will do it later on...

Will miss the old calendar then ?. Didn't had a look on the code yet, but will it be possible to specify a date format for the input field then?

couple notes about the pull request:

1) date-helper.js would be good to wrap in to anonimous function and for "use strict";:

!(function(Date){
   'use strict';
   ... code of date-helper
})(Date);

2) the filter thing (switch (strtoupper($filter))...) still need to be in the field file, it part of the logic, not the styling. If someone accidentally remove it then he will get wrong time on each save (if timezone not UTC).

3) you use strange construction:

var JoomlaCalendar = function (selector) {
  ...
  createInstance = function (element) {
    ...
    element._joomlaCalendar = new JoomlaCalendar.init(element);
    ...
  }
  ...
};
/** The Calendar object constructor. */
JoomlaCalendar.init = function (elem) {
};

You have mixed Class definition with setup.
It looks bad, very bad ?

Better split the thing, and all will be more easy:

var JoomlaCalendarSetup = function (selector) {
  ...
  createInstance = function (element) {
    ...
    element._joomlaCalendar = new JoomlaCalendar(element);
    ...
  }
  ...
};
/** The Calendar object constructor. */
JoomlaCalendar = function (element, options) {
};
JoomlaCalendar.updateTime = function(){...}
JoomlaCalendar.setDate = function(){...}

And why need this createInstance at all? just make element._joomlaCalendar = new JoomlaCalendar(element);

Some more will come later

2) the filter thing (switch (strtoupper($filter))...) still need to be in the field file, it part of the logic, not the styling. If someone accidentally remove it then he will get wrong time on each save (if timezone not UTC).

@Fedik do you think that the calendar should ALWAYS return UTC?

do you think that the calendar should ALWAYS return UTC?

well, the field always have a date in UTC (if talk about Joomla core),
the layout should get a final value to display, all changes should be inside the field.

Also maybe not bad idea to give into the layout the original value, something like

$data['value'] = $value; // modified depend from $filter
$data['rawvalue'] = $this->value; // original datetime in UTC

So who need it will have both.

@Fedik do you think that the calendar should ALWAYS return UTC?

+1 for always a UTC date saved in database.
As it is the only way to have a date free of timezone and culture manipulation. (you can then easily manipulate data datetime saved with JHtml::date() )

Before I go on and implement the other ones I would like some input from the translator team if this is something that will be approved so @infograf768 and @Bakual the ball is on your side ?.

Exactly what i think too! (needs translators feedback and better, a list, with all requirements that could be needed or not. That could help to create the right code for this!)

@laoneo yup, that functionality is intact, actually this is only used for display purposes in the input field, all the logic is based on '0000-00-00 00:00:00' format

@dgt41 about point 3)
Look next example:

var Example = function(){}
Example.init = function(){}

var t1 = new Example();
var t2 = new Example.init();

// Get constructor name
console.log(t1.constructor.name); // print Example
console.log(t2.constructor.name); // print nothing

// If you need to check object instance
console.log(t1 instanceof Example); // easy
console.log(t2 instanceof Example.init); // wt*?? :)

See the problem? ?

It more intuitive to have function as constructor, actually it how javascript work.
JoomlaCalendar.init also function, but it is property of JoomlaCalendar and use it as constructor it is wrong, it will work but it is wrong for my opinion. ?

I can't enter the date using directly the keyboard. I have to navigate to the right date in the popup using the arrows or mouse. If I have to go back to another month or even year, that accumulates to a lot of arrow presssing ?
Of course it is better than the old calendar where you couldn't use the keyboard to navigate the popup. But then you were able to directly input into the datefield which kinda made navigating the calendar popup unneeded ?

Selecting the time part from a list of 24/60 options is quite a bit tedious. That would go much faster using a simple text or number field. I would think about that again ?

Is there a reason why the date field has to be readonly?

Also keep in mind that currently you can enter the date in a format PHP can parse. That means you can either enter 2016-07-31 or 31.07.2016 (and some more variants I think) and it would save just fine.

Is there a reason why the date field has to be readonly?

Maybe I was too strict here, there should be a way to allow user input from keyboard. To explain the problem:

• the old way: user filled the form and pressed save. For non-gregorian calendars there was an event that was fired on submit and checked the calendar fields (parse-print) and then continue to submit.

• the new way: user filled the form and pressed save. All calendar fields exchange their input value to a data-value where the format is given (mysql), so no real calculation done at that point and the form continues to submit.

A solution could be adding an event listener on blur, means that the user clicked in the input and then clicked somewhere else, that will fire the parse-print sequence.

So why not: in short: prevent errors before you reach the submit stage (that might be after onValid, I don;t remember, have to check)

About the selects: these are working great for touch devices and are ok for desktops, also the implementation was way easier ?

@Fedik can you review the changes?

ok, here is my notes, please do not run away ?

1) I still think that the filter stuff must be moved out from the layout, I mean this part:

// If a known filter is given use it.
switch (strtoupper($filter))
{
  case 'SERVER_UTC':
  ...
  case 'USER_UTC':
  ...
}

2) About JoomlaCalendar javascript, sorry, but now you heavily mixed Object oriented with Functional programming.
And var self = JoomlaCalendar.getActiveCalObject(); just killing me ?

You doing:

var JoomlaCalendar = function (element) {}
JoomlaCalendar.setDate = function (date) {
    var self = JoomlaCalendar.getActiveCalObject();
    if (!date.equalsTo(self.date)) {
        self.date = date;
        JoomlaCalendar.processCalendar(self.params.firstDayOfWeek, date, self);
    }
};
...
JoomlaCalendar.close = function (element) {
    document.activeElement.blur();
    JoomlaCalendar.hide(element);
};
... there a loot more

// and Initit
...
elements[i]._joomlaCalendar = new JoomlaCalendar(elements[i]);

It is realy crazy ?

Instead of using strange JoomlaCalendar.getActiveCalObject() or JoomlaCalendar.close(element) and hard soup with self, use existing instance of JoomlaCalendar:

var JoomlaCalendar = function (element) {
    this.element = element; // Store "element" reference in current instance
    this.date = null; // Your self.date replacement
    this.params = {}; // Calendar params
}
JoomlaCalendar.setDate = function (date) {
    if (!date.equalsTo(this.date)) {
        this.date = date;
        this.processCalendar(this.params.firstDayOfWeek, date);
    }
};
...
JoomlaCalendar.close = function () {
    document.activeElement.blur();
    this.hide();
};


// and Initit
...
elements[i]._joomlaCalendar = new JoomlaCalendar(elements[i]);

Here is this is reference to curent JoomlaCalendar instance, same as in PHP $this inside a Class instance, easy ?
This will make the code more clear and the logic will be more easy to understand.

@Fedik how about now?

@Bakual I restored the functionality to enter manually a date in the field. There is a twist: the calendar opens and once you finish entering the value and pressing enter the calendar shows the date/mont/year as selected and you either press enter again to verify that this is correct or esc to close the calendar.

@infograf768 @Bakual @MATsxm quick question for the translators:
Right now all the strings (day month names, etc) are stored in the ini of each language. To optimise the process this would be better if they were in a javascript file, e.g.. system/calendar/locales/en-us.js. That way we won;t have many long data-* polluting the dom and since this is actually static file no php cycles will be needed to just deliver that file.
So the question is: would that be considered by the translators team? The effort for each language shouldn't be more than 10 minutes to finish the task.
The file would be (something like:

window.JoomlaCalLocale = {
    today      :  "Today",
    weekend    : [0, 6],
    wk         : "wk",
    time       : "Time:",
    days       : ["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"],
    shortDays  :  ["Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"],
    months     : ["January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"],
    shortMonths:  ["Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"],
    AM         : "AM",
    PM         :  "PM",
        am         : "am",
    pm         : "pm",
    dateType   : "gregorian"
};

@dgt41 is this ready for another round of testing then?

This one is ready for some tests. Here are some notes and the instructions:

• Calendar right now has only strings for en-UK and Fa-IR
• Calendar right now has to implementations, gregorian (en-UK) and Jalali (fa-IR)
• Do not try it with other languages as It (probably) WON'T work

Testing instructions

• Install persian language in your testing environment (which should be en-UK, joomla's default)
• Edit (root/administrator) /language/fa-IR/fa-IR.localise.php and comment out the custom JDate override

• Create an article and visit the publishing tab and play with the fields publish up, publish down, created (also observe the modified field).

• Edit administrator/components/com_content/models/forms/article.xml around line 99:

        <field name="publish_up" type="calendar"
            label="COM_CONTENT_FIELD_PUBLISH_UP_LABEL" description="COM_CONTENT_FIELD_PUBLISH_UP_DESC"
            format="%Y-%m-%d %H:%M:%S" size="22"
            filter="user_utc"
            todaybutton="true"
            weeknumbers="false"
            timeformat="24"
            showtime="false"
            filltable="true"
            singleheader="false"
            minyear="1970"
            maxyear="2030"
            weekenddays="0,6" />

Change format, today button, week numbers, time format, showtime, fillable, single header, miner, maxyear and weekend days and observe the changes in the article edit page.

• Change administrator language to persian and re edit the article, and follow the above step.

Report any problems

Did i miss something?

In the screenshot you can see it says WK
I think its supposed to say time?

Accessibility
Try tabbing into a calendar field. Calendar opens and cursor goes to hour
tab again and it goes to minutes
tab again and it goes to the next field but does not close the calendar

As a result if you are using the keyboard to navigate through the content publishing tab you end up with three open calendars and can not see the fields underneath it such as author alias

Before this PR I can set the day that the week starts on and the day(s) of the weekend in the en-GB.xml

< firstDay>0< /firstDay>
< weekEnd>0,6< /weekEnd>

With this PR any changes made here have no effect on the calendar

@brianteeman all reported issues should be solved with 80b5e42

The calendar now closes when you tab out.
Now the time doesnt display at all
The start of week and weekend still has no effect

The start of week and weekend still has no effect

I've deleted the relevant lines, now should work as expected

Now the time doesnt display at all

Do you have showtime="true"? in the article.xml?

Do you have showtime="true"? in the article.xml?
If I edit the field in the article.xml it works but in your PR you set it to false. https://github.com/joomla/joomla-cms/pull/11138/files#diff-b954a5e4248ac75dcf9086e50b845f82R106

For b/c you shouldnt have to change the xml to get the same formatting as now

The start of week and weekend still has no effect

Start of week ok now. Dont see anything for the weekend.

@Fedik I saw your comment, but document.querySelectorAll is also unsupported from IE8

EDIT: for a simple class it would be ok, so I will update the code, I think I use that in couple of places

@brianteeman Fixed the weekend logic, mind that right now there is no special treatment for that in the css, so you have to inspect the page to see the classes:

@dgt41 it working in IE8 I tested in #11671 ?
http://caniuse.com/#search=querySelectorAll

it not support advanced selectors, but for class it works very well

@Fedik I think IE8 will be happy with f223df9

EDIT: If for no particular reason querySelectorAll('INPUT') doesn;t work for IE I can append a class to the input and then use querySelectorAll('.input-class')

• I have Unsuccessful Tested.
• I have tested on article detail view and year not display properly. -

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11138.}

I have tested this item ? unsuccessfully on f70a683

I have tested on module detail view and year not display properly.

I have tested this item ? unsuccessfully on f70a683

@BhaveshTailored @bhavikTailored, the reported issue is fixed, can you try again?
Thanks for testing!

@yvesh can you check the karma test here if it's ok? Then I can go on and do some better coverage

@dgt41 hmm currently trying to debug your test locally. Jasmine breaks directly when you do a JoomlaCalendar.init(".field-calendar");

@dgt41 okay found it, you are missing a form in your html fixture (the calendar js is looking for that)..

<form name="formTest">
    <div class="field-calendar">
    //... 
</form>

fixes it

• Thanks @dgt41 .
• Now I have tested article detail and modules view and calendar is working.
• 

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11138.}

I have tested this item ✅ successfully on c93f5e9

I have tested this item ✅ successfully on c93f5e9

hmm karma is fine on my localhost but fails here, WTF?

Did you notice this?

I think that is what is causing the Travis to fail.

@Ruchiranga Am I triggering the page reload somehow?

@dgt41 probably from the test (on click elsewhere the popup closes) we talked about some days ago. We trigger a button click and that button is inside a form. As it worked locally i gave it no more thought, but looks like for Travis you need to move that outside the form.

I added this onsubmit="return false" attribute to the form tags to avoid forms reloading the page. May be that might help you.

I didn't think that a button may trigger a form submit...

@yvesh @Ruchiranga can I use https://github.com/francejs/effroi for mouse/keyboard simulation ?
$el.trigger('click') seems to fail miserably (or I do something stupidly wrong here)

@dgt41 I don't think that would be an issue. Did a quick search and found out a karma plugin for that as well https://www.npmjs.com/package/karma-effroi
Anyways, we didn't come across click trigger giving issues, but there were times we struggled with simulating ones like SHIFT + Click and some keyboard events.
Only thing as I see would be that previous tests (event triggers) would look kind of inconsistent with new ones.
@yvesh what do you think?

@dgt41 yeah should be no problem adding another library, just be sure to only load it for your tests and install it via npm (package.json) :-) Ping me on Glip if i can help with anything!

I tested Persian.
For people not aware, Persian numerals are displayed LTR.
Here are hints to be able to understand:
http://www.omniglot.com/language/numbers/persian.htm

First, 2 remarks:
commenting out the class fa_IRDate extends JDate in the fa-IR.localise.php (site) should not be done as we lose the Jalali date in columns and date fields.

The Date column is still using arabic numerals (western numerals) but not the calendar which uses Persian numerals.
Western numerals are also used in frontend:

Now, let's compare western calendar to Jalali when you want to enter a new date in a field:

As you can see, the "western" calendar does display "today" date and time when it is opened.
This is not the case for the Jalali calendar where the year displayed is 1970 (Unix date)

We also get 1970 opening the calendar when a date has already been set in the date field:

As it is blocked on 1970 (۱۹۷۰) we can't move backward with the Year arrows, only forward, but the year is not updated in the calendar itself.

Also remark that the time is displayed to the left of the date (I have no idea if this is correct: has to be checked with Persian TT)

Editing a date in Beez gives this weird result (still using 1970)

And in Hathor:

@infograf768 Thanks for taking the time to test this.

About class fa_IRDate extends JDate you are right it shouldn't be comment out, I will investigate another way to initiate the calendar's date.js so that the relative html gets the right (translated) numbers.

About the 1970: there is something missing in the persian language:
in the layout

 $minyear  = (isset($minyear) && $minyear != 0) ? $minyear : 1970;
 $maxyear  = (isset($maxyear) && $maxyear != 0) ? $maxyear : 2030;

in the field:

            $this->minyear      = (int) $this->element['minyear'] ? (int) $this->element['minyear'] : JText::_('JLIB_HTML_BEHAVIOR_CALENDAR_MIN_YEAR');
            $this->maxyear      = (int) $this->element['maxyear'] ? (int) $this->element['maxyear'] : JText::_('JLIB_HTML_BEHAVIOR_CALENDAR_MAX_YEAR');

so adding these two strings (admin/site):
JLIB_HTML_BEHAVIOR_CALENDAR_MIN_YEAR=1000
JLIB_HTML_BEHAVIOR_CALENDAR_MAX_YEAR=2000
will fix that. Mind these values are the ones the old calendar was using!

Thanks again

I just found out this morning before reading your reply that indeed, $minyear and $maxyear were not correctly set for fa-IR, but I do not think these should be defined by language strings.

They should be hardcoded imho in the fa-IR js files and fetched from there. Maybe similar to localLangNumbers.

Also, the equivalent min and max year depend on the calendar used
1970 - 2030 equivalent are
Jalali => 1348 - 1408
Hebrew => 5730 - 5790
Budhist => 2513 - 2573

Note: in vanilla.js the min-max are 1970-2050
But also look at
https://en.wikipedia.org/wiki/Year_2038_problem

That is not the Hebrew calendar. It is the Jewish calendar - not the same
thing

...both are used...
https://en.wikipedia.org/wiki/Hebrew_calendar
https://www.hebcal.com/converter/
etc.

Whatever.

@dgt41
As this is a new feature, I suggest you also think about these situations:
--- a fa-IR site wants to display the dates as Arabic Numerals instead of Persian. Can localLangNumbers be overriden?
--- a fa-IR site wants to display Gregorian calendar instead of Jalali (but keep the months and days names in Persian).
--- a Thai site wants to have the choice between Gregorian and Budhist calendar.

Note: drs-AF (Dari Persian) also uses the jalali calendar.

As the link says "The Hebrew or Jewish calendar (הַלּוּחַ
הָעִבְרִי, Ha-Luah
ha-Ivri) is a lunisolar calendar
https://en.wikipedia.org/wiki/Lunisolar_calendar used today predominantly
for Jewish https://en.wikipedia.org/wiki/Jew religious observances." It
is NOT the calendar of the language. Do not confuse the religion with the
language - they are not the same thing. Dont believe me - check any Israeli
government web site.They do NOT use the jewish calendar - that is
reserved predominantly
for Jewish https://en.wikipedia.org/wiki/Jew religious observances

On 12 September 2016 at 09:11, infograf768 notifications@github.com wrote:

...both are used...
https://en.wikipedia.org/wiki/Hebrew_calendar
https://www.hebcal.com/converter/
etc.

Whatever.

@dgt41 https://github.com/dgt41
As this is a new feature, I suggest you also think about these situations:
--- a fa-IR site wants to display the dates as Arabic Numerals instead of
Persian. Can localLangNumbers be overriden?
--- a fa-IR site wants to display Gregorian calendar instead of Jalali
(but keep the months and days names in Persian).
--- a Thai site wants to have the choice between Gregorian and Budhist
calendar.

Note: drs-AF (Dari Persian) also uses the jalali calendar.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11138 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8ZA377UsGun4azav7-3RhwZOjg5dks5qpQkhgaJpZM4JM8Zz
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

As I said: whatever... Everybody understood it is related to the religion. Let's not lose time on epiphenomena.

and lets not waste time telling @dgt41 he needs to support something in the
calendar that he does not

On 12 September 2016 at 09:37, infograf768 notifications@github.com wrote:

As I said: whatever... Everybody understood it is related to the religion.
Let's not lose time on epiphenomenons.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11138 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8bQ_QBwt30y7HPH0n9ZM73GTlVVlks5qpQ9LgaJpZM4JM8Zz
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

They should be hardcoded imho in the fa-IR js files and fetched from there. Maybe similar to localLangNumbers.

It's the same thing, it doesn't matter if it is in the en-gb.js or in the en-gb.ini. Also mind that this is overridable at field level as is:

            $this->minyear      = (int) $this->element['minyear'] ? (int) $this->element['minyear'] : JText::_('JLIB_HTML_BEHAVIOR_CALENDAR_MIN_YEAR');
            $this->maxyear      = (int) $this->element['maxyear'] ? (int) $this->element['maxyear'] : JText::_('JLIB_HTML_BEHAVIOR_CALENDAR_MAX_YEAR');

As this is a new feature, I suggest you also think about these situations:
--- a fa-IR site wants to display the dates as Arabic Numerals instead of Persian. Can localLangNumbers be overriden?
--- a fa-IR site wants to display Gregorian calendar instead of Jalali (but keep the months and days names in Persian).
--- a Thai site wants to have the choice between Gregorian and Budhist calendar.

It is doable, the javascript side is very easy (almost ready as is, only need to expose one var translate that will be set from php) but the php side needs some though:

• calendar field needs to change translation or use local/gregorian helper according to ?? Language + user group (is the only combination that makes sense to me).

I will suggest to leave this for J4 where we could also bring moment.js (although is a big B/C break)

@dgt41
The reason I think it should be hardcoded in the specific js file rather than in the xx-XX.ini is simple:
People can override the lang strings JLIB_HTML_BEHAVIOR_CALENDAR_MIN_YEAR and MAX thus killing the whole calendar.

For the rest, yep, for J4 indeed, just wanted to describe some possible improvements.

The reason I think it should be hardcoded in the specific js file rather than in the xx-XX.ini is simple:
People can override the lang strings JLIB_HTML_BEHAVIOR_CALENDAR_MIN_YEAR and MAX thus killing the whole calendar.

But that is a feature: this way you can specify the years range that the calendar should work. In fact this must be extended a bit so devs can specify exclusion dates (e.g. weekends, or bank holidays, etc)

Note: in vanilla.js the min-max are 1970-2050
But also look at
https://en.wikipedia.org/wiki/Year_2038_problem

This is not a javascript/php limitation. It's a limitation of 32bit versions of the languages (32bit cannot go beyond 2038). Switch to 64bit and problem is solved.
As I already suggested to @wilsonge there should be a note at the requirements of joomla stating that 32bit installations of PHP will fall into this limitation. Same goes for the browsers, javascript side (tho I haven't test the latter)

@infograf768 what is the state of your test, since you added the missing strings in fa-IR?

@infograf768 what is the state of your test, since you added the missing strings in fa-IR?

@dgt41
I am not in favour of doing this in a language string. People can mess with it at will and kill the calendar.
As I said, I think the variable should be hardcoded in one of the fa-IR js files in /media/system/js/calendar-locales/date/fa-IR/

Ok, will do that

@infograf768 can you check?

@dgt41 please correct the bug above. then we can see what can be done for hathor and beez

we can see what can be done for hathor and bees

@infograf768 you mean the css part?

@dgt41
Yes for beez as we get this when hover the top fields:

Also: drs-ir.js is not one of joomla languages. In fact, it does not exist at all. You can take it out of this patch.
The language that uses Jalali calendar is prs-AF (Dari Persian, Afghanistan country code)
https://en.wikipedia.org/wiki/Dari_language
It would also need the jalali helper then.

Question:
I see you use the language tag to define the $helperpath in libraries/cms/html/html.php and libraries/joomla/form/fields/calendar.php

        if (is_dir(JPATH_ROOT . '/media/system/js/calendar-locales/date/' . strtolower($tag) . '/'))
        {
            $helperPath = 'system/calendar-locales/date/' . strtolower($tag) . '/date-helper.min.js';
        }

Is it possible to make the Jalali js helper files independant from the tag, i.e. reusable by any language that would need it? In our case fa-IR and prs-AF for example but other possible future Joomla languages as Pashto.

I mean can we fetch first the $localesPath, extract from there the dateType : "jalali", and then use a common file date-helper-jalali.js?

Instead of this:

We would have:

Another solution would be to add the dateType in the xx-XX.xml metadata (There is already a PR adding NativeName to them see: #12036 ) and fetch that value from there.

Same could be done for the Jewish, Budhist (Thai), Hijri (Islamic Lunar) calendars in the future.

Note:
this is how drupal does: https://www.drupal.org/project/calendar_systems

@infograf768 So here is what I did:

Another solution would be to add the dateType in the xx-XX.xml metadata

I named that calendar

We would have:

I created a structure
calendar-locales
--date
---gregorian
---jalali

About the css part: now front/back end templates all use the same css. Beez is the only one that needs some attention due to the hovering effect that is applied in the template.css
preview:

I have some issues here when there are calendar fields in the page:

Admin backend (English):

Also, when the new metadata is not added in a language xml we get an error:
I guess we have to check if it is available in language.php with something like:

    /**
     * Getter for the language tag (as defined in RFC 3066)
     *
     * @return  string  The language tag.
     *
     * @since   __DEPLOY_VERSION__
     */
    public function getCalendar()
    {
        if (isset($this->metadata['calendar']))
        {
            return $this->metadata['calendar'];
        }
        else
        {
            return 'gregorian';
        }
    }

And the block should be changed to

/**
     * Getter for the calendar type
     *
     * @return  string  The calendar type.
     *
     * @since   __DEPLOY_VERSION__
     */

Otherwise, the metadata trick works fine! ?

@infograf768 fixed the Language part. About the multiple calendars I guess this is something with browser cache, as I don't get it:

no cache. firefox macintosh. immediately solved by adding dropdown-menu
?

@infograf768 the j-calendar class is a copy of dropdown-menu (without some shadows)...

Here is a movie.
https://www.dropbox.com/s/6k0zf9pj7nb32w4/calendar.mp4?dl=0

Same on Safari.
PHP 5.4.4 on staging

@infograf768 I did it in another way, let me explain why I didn't won't to use dropdown-menu:
This is a bootstrap class and using this might become problematic in the future, or if the class is altered by the user/template. Specifying our own class should be safer. Just as a note with a less file we can still do something like .j-calendar { &:extend(.dropdown-menu); }

@dgt41

I found out the issue:
In fact the css is not loaded, I don't know why.
I added in Isis index.php
JHtml::_('stylesheet', 'system/calendar-vanilla.css', array(), true);
and it worked fine.

Ok, I 've added the removed files to script.php and I think this is good to go now

@dgt41
Sorry, but this is not the solution.
calendar-vanilla.css is still not loaded here.

@infograf768 check the code:
layouts/joomla/form/field/calendar.php line 91

JHtml::_('stylesheet', 'system/calendar-vanilla.css', array(), true);

Probably something in your setup

EDIT:
@infograf768
I know what's the problem in your setup:
you still have layout overrides in isis and protostar, just delete them

UX police requested more buttons, so here they are:

Also the functionality is altered a bit when the time picker is enabled, so clicking in a specific day will not close the pop up, so that the user would be able to select the time (if they want to alter the current time, which is used by default).
For the calendar without time picker enabled the functionality should be as it was before

Done?

On 16 September 2016 at 23:44, Dimitri Grammatikogianni <
notifications@github.com> wrote:

UX police requested more buttons, so here they are:
[image: screen shot 2016-09-17 at 01 43 40]
https://cloud.githubusercontent.com/assets/3889375/18603217/4f68fcb4-7c78-11e6-8e0c-795f5daee889.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11138 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8drkvuJEWCCNqb1N184x5UddIoRMks5qqxvogaJpZM4JM8Zz
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I was hopping that you will come up with the right term

I know what's the problem in your setup:
you still have layout overrides in isis and protostar, just delete them

Indeed! These were remnants of an early stage of this PR (like 2-3 days ago).
Now testing new code since

Any reason not to use "Save" instead of "Apply"? Apply imho does not reflect the fact that the popup will also close. (Save & Close would be too long)

And "Close" instead of "Exit" ?

These would be imho more consistent with the terms we generally use in the UI.

Concerning beez
There is a small correction to make to get the calendar image instead of that semi-button:

diff --git a/templates/beez3/css/general.css b/templates/beez3/css/general.css
index c49cb95..26268c5 100644
--- a/templates/beez3/css/general.css
+++ b/templates/beez3/css/general.css
@@ -140,5 +140,5 @@
 }
 /* Calendar */
-#jform_publish_down_img {
+#jform_publish_down_btn {
    width: 18px;
    height: 18px;
@@ -148,5 +148,5 @@
    vertical-align: middle;
 }
-#jform_publish_up_img {
+#jform_publish_up_btn {
    width: 18px;
    height: 18px;

to get

instead of

Any reason not to use "Save" instead of "Apply"?

"Save" isn't really correct because nothing is actually saved by pressing that button. But I agree "Apply" isn't optimal either. I'd go with "Insert" like we do with the editor "Image" popup.

I am testing this,
trying to adapt my code to use the new calendar JS, i have JS

• to add calendar fields at browser 's DOM via JS according to user actions
• to detect calendar field change and submit form
• other JS related to calendar

it is not only my extensions,

• several calendar related extensions will need to be updated
• and also the subform field

this should go to J3.7 not in a minor Joomla version

this should go to J3.7 not in a minor Joomla version

Indeed. It can't be else as it requires new js files for the various languages + a change in the metadata xml for most languages.

I'd go with "Insert" like we do with the editor "Image" popup.

OK with this here.

I'd go with "Insert" like we do with the editor "Image" popup.

Done. Also:
Remove Boostrap specific classes
Remove inline styling
Move files to subfolder fields (this will make sense with J4 ;) )
Simplified the css

Found some issues:

• Try setting a date for "Finish Publishing" (eg in an article), save and then try to delete that value again. It will keep the previously saved value.
• Please don't make clicking into the input field activate the calendar. We have a dedicated button for that. If you want to manually insert a date into the field it is disrupting to have the calendar open.

Please don't make clicking into the input field activate the calendar. We have a dedicated button for that. If you want to manually insert a date into the field it is disrupting to have the calendar open.

That WON'T be possible due to the fact that the input needs to be validated by the calendar (the date-helper.js needs to parse the input). So if it is invalid then the calendar stays open till the user corrects that.

Try setting a date for "Finish Publishing" (eg in an article), save and then try to delete that value again. It will keep the previously saved value.

I made a mistake, the buttons should be clear, today and close. The insert is useless! I'll fix that

That WON'T be possible due to the fact that the input needs to be validated by the calendar (the date-helper.js needs to parse the input). So if it is invalid then the calendar stays open till the user corrects that.

Why does it have to validate the date? And what exactly does it validate?
While testing a bit further I found that you actually can't enter a value with the keyboard alone. You need the mouse.

• You can't use Tab to jump to the next field. While the calendar vanishes and all looks fine, when saving the value is discarded and the old value is saved. When pressing Enter the calendar updates and all looks even better, but if you now press Tab to go to the next field the value still is discarded. Looks like you actually have to click into the calendar to make the selection stick.
• You can't enter dates in other formats than english. Eg 31.8.2016 is recognized as 1970-02-05. That works with the old calendar because PHP can actually interpret those date formats fine.

Both issues imho need to be corrected before this cna be merged.

I made a mistake, the buttons should be clear, today and close. The insert is useless! I'll fix that

How is the "Insert" useless? I can't enter a date and time without pressing that button. But yes, a clear button would make sense.
However again, it has to be possible to clear that value without pressing any mouse buttons or interacting with the popup.

While testing a bit further I found that you actually can't enter a value with the keyboard alone. You need the mouse.

when the calendar comes up just type the date and press enter. If it's valid date the calendar will adjust to the year/month/day time. then press esc or click close.

You can't use Tab to jump to the next field. While the calendar vanishes and all looks fine, when saving the value is discarded and the old value is saved. When pressing Enter the calendar updates and all looks even better, but if you now press Tab to go to the next field the value still is discarded. Looks like you actually have to click into the calendar to make the selection stick.

Without ENTER at the end of your input the value is not processed. Same behaviour in many places (tags) in Joomla

You can't enter dates in other formats than english. Eg 31.8.2016 is recognized as 1970-02-05. That works with the old calendar because PHP can actually interpret those date formats fine.

Have to check this

when the calendar comes up just type the date and press enter. If it's valid date the calendar will adjust to the year/month/day time. then press esc or click close.

Yes, now Enter works as expected. I guess you fixed that now?

Without ENTER at the end of your input the value is not processed. Same behaviour in many places (tags) in Joomla

Actually no. Tags behaves different. If you enter a new Tag and tab away, the input is discarded right away, making it clear it didn't save. If you delete a tag using the keyboard and tab away, the tag stays deleted and saves as expected. However in the case of the calendar, you can add or change a date and tab away and it looks like it is fine. No indication at all that something could not be right. But as soon as you hit the save button the value is replaced with the original one, discarding the input.

No indication at all that something could not be right. But as soon as you hit the save button the value is replaced with the original one, discarding the input.

OK, I will also add a listener for tab as well.

You can't enter dates in other formats than english. Eg 31.8.2016 is recognized as 1970-02-05. That works with the old calendar because PHP can actually interpret those date formats fine.

This is a little more complicated than I though. Let me explain the process:
The script (calendar) needs to parse the input with the use of data-helper.js. The problem is the parser reg exp: https://github.com/joomla/joomla-cms/pull/11138/files#diff-295073f18bf4726aebb25eb367b63e52R223
If you can help patch this to be more flexible, please do

Another one

• Setting the format in the XML to "%d.%m.%Y" properly formats the date in the input field. But the calendar doesn't parse it right. Trying to edit the date "11.08.2016" results in the calendar jumping to 5th February 2017.
• The XML attributes todaybutton and showtime don't seem to work (they are specified in the article.xml). filltable doesn't seem to work either, but I didn't know what I had to look for. Shouldn't timeformat be something specified by the language pack? Imho it is not something an extension developer should be deciding but rather it's something that is depending on the culture or the user. I have my doubts about the usefullness of the singleheader attribute. It's nice from a designers perspective, but it is defined by the extension developer who likely doesn't care about it. And it should be the same on the whole site for consistency anyway, not different depending on the extension.

OK, I will also add a listener for tab as well.

If that is possible, that would certainly help a lot.

If you can help patch this to be more flexible, please do

I'm sorry, but regex definitively isn't my strength. However it may be worth to look at the current calendar because that one at least can read a different format if it is entered in the format specified in the XML. Eg if the XML specifies "%d.%m.%Y", you can enter 31.8.2016 and the calendar works flawless.
It fails as well if the XML specifies "%Y-%m-%d" and you enter 31.8.2016 and want to open the calendar after you entered the date. However that isn't a big issue since you still can save it without issues, which with the new calendar doesn't work.
It is afaik the reason why we have to enter the format in this format (JavaScript understands that) and not in the one for the PHP date class.

However it may be worth to look at the current calendar

data-helper.js is almost identical to the old calendar (the functions are at the end of the old calendar.js). The only difference is that each function now can be triggered for two different calendars (gregorian and anything else). But I will investigate further.

EDIT
I've tested with 1999.01.01 00:00:00 and once i pressed enter (or tab) i get 1999-01-01 00:00:00
which is ok.
Changing the order year,month,day will never work (or at least I cannot think of a way to parse something in a random order, esp for month-days and that will work out reliably). But if you have any ideas, we can try them out

Thoughts:
Concerning entering manually a date in the calendar field, it is a real feeble point in Joomla.
With the existing calendar as well as with the new one.

It is totally impossible to know what should be the right format to enter (%Y-%m-%d or whatever else defined in the xml).
And it is even worse for non-English as there is no control on the xml field (a French user would typically enter %d-%m-%Y).

The only real solution I see would be to force the use of the calendar widget to enter any date in the field. Using readonly is no good as it also hides the widget.

Any idea?

Concerning AM/PM
Although setting timeformat="12" indeed displays the choice between AM and PM when showtime="true", the Unix date entered in the field does not care about it and displays first the local time by default based on 24h.

For example we have this xml

        <field name="publish_up" type="calendar"
            label="COM_CONTENT_FIELD_PUBLISH_UP_LABEL" description="COM_CONTENT_FIELD_PUBLISH_UP_DESC"
            format="%Y-%m-%d %H:%M:%S" size="22"
            filter="user_utc"
            todaybutton="true"
            weeknumbers="false"
            timeformat="12"
            showtime="true"
            filltable="true"
            singleheader="false" />

we get this display:

Here it is morning time: 8:43:20 on my computer.
My server Time Zone is Paris: UTC + 2

Let's choose a date, PM on

We get in the field:

Should be: 2016-09-13 20:43:20

Other issue, after saving AM-PM on OR NOT, the time changes. I takes off 4 hours from the original field display

In this case I would have expected the real time displayed AND saved to be
2016-09-13 20:43:20
or, at least to be pure UTC, i.e. 2016-09-13 18:43:20

EDIT:
My test show that each time the item is saved (an article for example), 4 hours are taken off from the date in the field.

Changing the order year,month,day will never work (or at least I cannot think of a way to parse something in a random order, esp for month-days and that will work out reliably). But if you have any ideas, we can try them out

It at least has to work with the format specified in the XML. Which the current calendar does. You should be able to use that format in JavaScript. I don't know how the current calendar does it but I'm quite sure it uses that format somehow.
The calendar doesn't have to work if the entered format is different from the one specified in the XML, but you still should be able to enter the date manually in any format PHP can understand. Otherwise we're going to restrict the field for no reason and it isn't B/C.

It is totally impossible to know what should be the right format to enter (%Y-%m-%d or whatever else defined in the xml).
And it is even worse for non-English as there is no control on the xml field (a French user would typically enter %d-%m-%Y).

The point is that today it doesn't really matter. PHP is able to understand the format entered in many cases. At least I don't remember having issues entering the german format (31.8.2016) as long as I wrote the year with 4 numbers.

I can confirm that currently in Joomla if you type the date like that it
will be saved correctly
Also if you type an invalid date such as 31.09.2016 it will be corrected on
save

(I learnt something new today)

On 18 September 2016 at 10:02, Thomas Hunziker notifications@github.com
wrote:

It is totally impossible to know what should be the right format to enter
(%Y-%m-%d or whatever else defined in the xml).
And it is even worse for non-English as there is no control on the xml
field (a French user would typically enter %d-%m-%Y).

The point is that today it doesn't really matter. PHP is able to
understand the format entered in many cases. At least I don't remember
having issues entering the german format (31.8.2016) as long as I wrote the
year with 4 numbers.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11138 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8Wino0dzM660Fpo9acCHYE1wXIfGks5qrOHwgaJpZM4JM8Zz
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

In the existing calendar, one can use periods or hyphens, even mixed, as long as they are in the right order (day month year or year month day).
It accepts 31.12.2017 and 2017.12.31 but also 2017-12.31 or 31.12-2017

but you still should be able to enter the date manually in any format PHP can understand.

Sorry not with the calendar field. Create a new text type field and enter any text you want, the calendar HAS to stick to the given format

Concerning AM/PM

Haven't seen that one

Also if you type an invalid date such as 31.09.2016 it will be corrected on
save

The new calendar will correct that before save, that's the difference with the old one, this one VALIDATES the entered value where the old one didn't care for the manually inputed value

In the existing calendar, one can use periods or hyphens, even mixed, as long as they are in the right order (day month year or year month day).

This is also true for the new one. I mean the Date parse and print functions are a copy paste of the old one!

It is totally impossible to know what should be the right format to enter (%Y-%m-%d or whatever else defined in the xml).

That can be fixed

It is totally impossible to know what should be the right format to enter (%Y-%m-%d or whatever else defined in the xml).

Fixed, placeholder indicates the given format:

Fixed, placeholder indicates the given format

but placeholder should be a language string

but placeholder should be a language string

What do you mean? Something more explanatory?

Y m d H M S
are meaningful only for people knowing English ?

also the percentage in the placeholder, will mean what to the user ? that user should type percentage ?

@dgt41 i was about to report you an issue with placeholder not using the placeholder (hint). (broken in a B/C usage, with JHtml::_('calendar'))

So, i'm against using format (nor description) as the placeholder, and placeholder to use only hint attribute (consistency).

And to keep the placeholder usable to not have a B/C break (eg. when using a calendar picker as a search filter, and not using a label (only the input). There, the placeholder is "free" explanatary text).

@dgt41 sorry forget my previous message, i realize your change does not break placeholder (com_banners > tracks > search tools : still ok using the hint attribute ;-) )

But still an issue to set placeholder (as it worked before PR) when using JHtml, eg. this code working currently on 3.6.2 :
JHtml::_('calendar', $this->state->get('filter.from'), 'filter_from', 'filter_from', '%Y-%m-%d', array('placeholder' => JText::_('STRING_FROM'), 'class' => 'input-small'));

ut still an issue to set placeholder

@JoomliC test it again

@dgt41 do you mean a new test with JHtml::_('calendar', $this->state->get('filter.from'), 'filter_from', 'filter_from', '%Y-%m-%d', array('placeholder' => JText::_('STRING_FROM'), 'class' => 'input-small')); ?

If yes, did it, and still the same.
My placeholder is not displayed, and i have "Y-m-d" instead.

I will be away for the day, but i could check too for this issue later ;-)

@JoomliC Ahh, JHtml... is not passing all the attributes to the Jlayout

The only real solution I see would be to force the use of the calendar widget to enter any date in the field. Using readonly is no good as it also hides the widget.

@infograf768 That was my initial approach here, but then I changed to fulfil this request #11138 (comment)
Personally I still believe that not allowing user to input the value manually will be the best UX. Users like to click, devs like to write!

Personally I still believe that not allowing user to input the value manually will be the best UX. Users like to click, devs like to write!

Complete nonsense. When was the last time you entered your birthday in a form using a calendar popup? I doubt users want to first click 40 times (depending on age) to go to the right year and the click several times to get the month and then click the day. You need to be able to manually enter a date or your UX and accessibility fails.

Sorry not with the calendar field. Create a new text type field and enter any text you want, the calendar HAS to stick to the given format

Sorry to say, but no. If the existing calendar doesn't enforce that and works fine without, you can't change it in the new calendar to enforce it. If you do make it optional and disabled by default or it isn't B/C. It will break functionality.

As for using the format as placeholder, please remove that. It's not providing useful information for the user and isn't possible to localise (what does Y-m-d H:M:S mean for a german or chinese guy?). It would be better to provide a hint in the XML and use a language string there (which is already possible) if someone wants to do that.
But that is an issue that is outside the scope of this PR as it exists today already.

What you need to solve is that the calendar supports other formats than "%Y-%m-%d %H:%M:%S". It's a must it can understand "%d.%m.%Y %H:%M:%S" when it's specified in the XML. Currently this format results in that:

In future, we need to improve the calendar so it takes a localised format instead of the current hardcoded. in the XML. Because different languages show the dates in different formats. Showing a date in the format YYYY-MM-DD to a german, french or probably most non-english users is completely wrong.
This doesn't have to be solved with this PR, but it should be kept in mind and certainly shouldn't make it harder.

@dgt41
please look at the am/pm issue + the 4 hours taken off when saving.

Complete nonsense. When was the last time you entered your birthday in a form using a calendar popup? I doubt users want to first click 40 times (depending on age) to go to the right year and the click several times to get the month and then click the day. You need to be able to manually enter a date or your UX and accessibility fails.

I will not argue here, as we approach it in complete different angle

Sorry to say, but no. If the existing calendar doesn't enforce that and works fine without, you can't change it in the new calendar to enforce it. If you do make it optional and disabled by default or it isn't B/C. It will break functionality.

So how many other fields in the front end DO NOT have javascript validation?
I cannot follow your idea of B/C, I mean obviously the old calendar was allowing whatever, but setting some rules (that should exist from day 1) is B/C???

Anyways placeholder and format are fixed.

@infograf768 I will need some help as this is something that happens in the php side...

So how many other fields in the front end DO NOT have javascript validation?

By default there is no JS validation on the forms. The extension developer has to enable JS validation in the XML definition by adding a specific class. See https://docs.joomla.org/Client-side_form_validation.
So it is completely optional.

I cannot follow your idea of B/C, I mean obviously the old calendar was allowing whatever, but setting some rules (that should exist from day 1) is B/C???

Backward Compatibility means if something worked in 3.6, it has to work as well in 3,7. In 3.6 you can enter the date in any format that is accepted by PHP and it works. If that changes with this PR, then it is obviously not B/C. If your validation only accepts a very specific format, then you're validation is way to strict and doesn't make sense. It's likely also the reason why that rule never existed.

If your validation only accepts a very specific format, then you're validation is way to strict and doesn't make sense. It's likely also the reason why that rule never existed.

I rest my case!

It's seriously a B/C break to implement validation rules on a form field!? Oy vey...

It's seriously a B/C break to implement validation rules on a form field!? Oy vey...

Imho, when it is restricting more than necessary, reducing functionality in the process, then yes it is a B/C. If it is only restricting stuff that wouldn't pass the PHP date processing, then no (eg preventing sending random strings). If you can do the validation generic enough so it passes any valid formats, then it is fine.
As long as we don't have a localised format, it is important to allow users entering the date in any format.

Thanks for fixing the tabbing and respecting format attribute now. That works. It's even possible to clear the value directly now ?
Also the other attributes work now fine.
There is a small issue with the border if the "Today" button is disabled, "Week Numbers" have an effect on it as well:

There is a small issue with the border if the "Today" button is disabled, "Week Numbers" have an effect on it as well

There are classes all over the elements, someone needs to play with the css a bit (i mean this is totally bear minimum from aesthetics point of view)

@infograf768 I will need some help as this is something that happens in the php side...

we never use am-pm in the present calendar, but, for sure, saving does not take off 4 hours from waht is set in the field. Don't know either where to look to solve this.

@infograf768 it should be fine now

@JoomliC Ahh, JHtml... is not passing all the attributes to the Jlayout

@dgt41 i confirm it's ok now with JHtml and placeholder! ?
https://github.com/joomla/joomla-cms/pull/11138/files#diff-b01d47e3fbe4a8e5fb4987f4df64b291L973 : does it means class not anymore available in JHtml calendar markup ?

Personally I still believe that not allowing user to input the value manually will be the best UX. Users like to click, devs like to write!

Some users (not devs!) enter date in manual to go faster to enter past date or future date far away in time. (real statement from my everyday-support life ;-) )
In the same time, to allow to manually enter a date could be needed (required) for users with disabilities (currently, UX needs a11y minor improvement to use shift+tab to navigate back in form, and inside calendar picker...).

Addtional note following some previous comments: the current calendar picker has a function to click ("select and hold") on navivation arrows, and get a dropdown list of years/months. Not a priority, but could be an idea to improve later fast year/month navigation ? (eg. dropdowns on click on year / month).

Not a priority, but could be an idea to improve later fast year/month navigation ?

Honestly I am against this, but an alternative for years and months could be instead of left right buttons the usage of select tags, and that shouldn't be too much work to accomplish. This is UX territory and without real tests one can only guess or copy similar functionality from other well used pickers.

does it means class not anymore available in JHtml calendar markup ?

The code is:

        $readonly     = isset($attribs['readonly']) && $attribs['readonly'] == 'readonly';
        $disabled     = isset($attribs['disabled']) && $attribs['disabled'] == 'disabled';
        $autocomplete = isset($attribs['autocomplete']) && $attribs['autocomplete'] == '';
        $autofocus    = isset($attribs['autofocus']) && $attribs['autofocus'] == '';
        $required     = isset($attribs['required']) && $attribs['required'] == '';
        $filter       = isset($attribs['filter']) && $attribs['filter'] == '';
        $todayBtn     = isset($attribs['todayBtn']) ? $attribs['todayBtn'] : true;
        $weekNumbers  = isset($attribs['weekNumbers']) ? $attribs['weekNumbers'] : false;
        $showTime     = isset($attribs['showTime']) ? $attribs['showTime'] : true;
        $fillTable    = isset($attribs['fillTable']) ? $attribs['fillTable'] : true;
        $timeFormat   = isset($attribs['timeFormat']) ? $attribs['timeFormat'] : 24;
        $singleHeader = isset($attribs['singleHeader']) ? $attribs['singleHeader'] : false;
        $hint         = isset($attribs['placeholder']) ? $attribs['placeholder'] : '';

so probably needs all the possible tags that are available in the field.
That makes me wonder if an introduction of JHtml::_('renderField.calendar', array()); would make more sense, as right now many fields are using different ways. The old calls will just be alias to the new one, and deprecated, so later on we end up with one way for all the fields. Obviously this is something that won't happen in this PR...

AM/PM now works fine, i.e. when saving we get the correct Time.
Also, 4 hours are no more substracted from the time set in the field when saving.

Compared to the present calendar, the main difference is that we have still issues when entering the date manually in the field:

Example one: Enter the date manually in English order (year-month-day)

gives when using Enter

And when article saved:

BUT when I click on the calendar icon again, I get:

Which is normal imho as we are limited to UNix date 1970.
We can't navigate back in years using the calendar arrows until a year < 1970.

But we can do that in the present calendar:

Example two: enter the date in the field using day-month-date

When using Enter, we get:

Which is not B/C

AM/PM now works fine, i.e. when saving we get the correct Time.
Also, 4 hours are no more substracted from the time set in the field when saving.

Nice!

Compared to the present calendar, the main difference is that we have still issues when entering the date manually in the field:
BUT when I click on the calendar icon again, I get:
But we can do that in the present calendar:

The difference here is that the old calendar doesn't enforce the minimum year something that the new one is doing thus the 1970 instead of 1948. Maybe the 1970 is not a good choice, minYear = 1916 will give a 100 till today.

Example two: enter the date in the field using day-month-date

I do get the same with the old calendar:

The difference is that the old calendar did not validate the date (whatever is typed will go to server) and thus if the calendar is not opened and a day picked (with the new is always the case and done automatically before save) the entered value will rich the server as is. Again the new calendar will ALWAYS validate the date given before sending it to back end!
So the failure here is entering an invalid date, date should be in the format &Y-&m-%d or whatever is specified in the format of the calendar field.
This is not a BUG this is an improvement, and also I don't think there is a B/C break when we enforce validation rules!

but an alternative for years and months could be instead of left right buttons the usage of select tags, and that shouldn't be too much work to accomplish.

Well, i didn't say the dropdonw was the best way (and imo, not very nice to use).
But what do you mean about "select tags" ?

so probably needs all the possible tags that are available in the field.

I think to add the attributes that could be used by JHtml::calendar before (in case on or more third party extensions used them).
But honestly, i see only class missing. ;-)

That makes me wonder if an introduction of JHtml::_('renderField.calendar', array()); would make more sense, as right now many fields are using different ways. The old calls will just be alias to the new one, and deprecated, so later on we end up with one way for all the fields. Obviously this is something that won't happen in this PR...

?
So what about adding a "todo" in the comment of JHtml calendar ? (with a to be deprecated when someone will create a JHtml::_('renderField.calendar', array()) ... ?

The difference here is that the old calendar doesn't enforce the minimum year something that the new one is doing thus the 1970 instead of 1948. Maybe the 1970 is not a good choice, minYear = 1916 will give a 100 till today.

The issue with min/max year set as default is that you never know what a use want to enter as as date, and for which usage. So, to have limits or not (didn't check if old calendar has limits...) should stay as it was with older calendar. ;-)

Just to add a note: you are doing a wonderful job, but you may be a crazy boy! ;-)

The issue with min/max year set as default is that you never know what a use want to enter as as date, and for which usage.

The field value acceptance is set by the developer, not by the end user. Right now there are the values of min/max year from the language, but a dev can override those in the field xml. Eg if you want to have date of birth then min might be 1916 and max 1998 (if you are accepting >18 years old)
Or if you want to set up reservations for a hotel then min year might be

function () {
date = new Date();
y = date.getYear();
return y;
}

Cool?? (this needs to be expanded more to cover month/day, with something like not allowed dates)

So what about adding a "todo" in the comment of JHtml calendar ? (with a to be deprecated when someone will create a JHtml::_('renderField.calendar', array()) ... ?

I wouldn't do that before I get an ok from PLT, as there might be a reason that won't be accepted

Well, i didn't say the dropdonw was the best way (and imo, not very nice to use).
But what do you mean about "select tags" ?

So instead of having < September > we could have a <select><option>September</option></select>
Same for the year

The field value acceptance is set by the developer, not by the end user. Right now there are the values of min/max year from the language, but a dev can override those in the field xml. Eg if you want to have date of birth then min might be 1916 and max 1998 (if you are accepting >18 years old)

I think by default it has to be without any min/max like the current does. Otherwise extensions will have to be updated to reflect that change. Eg an extension asking for birthdays needs an update or people like JM are not able to fill out the form anymore. So that one isn't B/C in its current state.
Setting min/max is probably not needed in most cases anyway.
In practice the required min/max will likely be depending on current date anyway (eg only in past for a birthday field), and not be a fixed year.

Btw I did a PR #12102 which may help with the formatting issue. If the format is localised, imho we can live with enforcing the format with the calendar (still not a fan though). If it is hardcoded like today, I would be strongly against only accepting the english format (which is very non-intuitive for a user in Germany).

@infograf768 @Bakual About the format:
it's true that the old gregorian calendar would accept anything typed in the field and will not try to validate it. That is not the case for the old Jallali calendar which always validates the input. So even the old calendar is not having a consistent way of handling this. My personal opinion is that the calendar should always validates the typed text, similar to what is happening to other fields.

@Bakual #12102 nice!

@dgt41
Please take off the calendar metadata from the installation en-GB.xml
It is useless. We do not need firstday, weekend or calendar there.

@dgt41
Here are a completed fa-ir.js + the prs-af.js (which also uses jalali) + fr.js for French
3lang.zip

I have tested this item ✅ successfully on

Can't open the issue on the tracker, so I paste the message directly on github.

@laoneo by any chance, have you tested this against custom fields?

Works with custom fields as well ?.

All the new parameters are missing in the field configuration, but when this one get's merged, I will add them then to the custom fields calendar parameters.

Good work!

I have tested this item ✅ successfully on bbc0e66

RTC based on the last 2 tests. Thanks!

I think we need more than 2 good tests on this one, Tobias. ?

@dgt41 didn't check the last changes, but now the placeholder is broken in Banners > Tracks > Search Tools

Some additional comments on minor design issues (Screenshot attached on Firefox, mac) :

• Columns don't have the same width (tested on Firefox) giving strange feeling when hovering through dates
• Consistency of clear button with Today and Close (cursor pointer, underline on hover)
• Global centering of month, year, Today btn (a bit on the right...)
• Vertical alignment of Time with dropdown ?

Not yet have played with attributes, but will soon ;-)

Back to pendig than

@JoomliC I haven't really done any serious work on the css part, but if you like you can do so. My idea was to provide the functional base and the UX/UI team would do the painting...
I'll have to investigate why placeholder is failing

Should this feature not get the 3.7 label?

Should this feature not get the 3.7 label?

There is no such label ?
If you mean the PR-3.7.x label, that one is automatically assigned based on the target branch of the PR. Since this PR is done against staging, the PR-staging label is used.

@Bakual yes exactly.

So I suggest to change the base branch of this PR to 3.7.x and then doing another round of testing.

@laoneo with 123 commits rebase will be nightmare ?. If that's the case then I will redo this directly against 3.7

Squash the commits first, then it is only one ?

There are only two conflitcs actually. One for the script.php (conflicts with #11588) and the other one for the html.php (conflicts with #10771).
Both are very simple to solve. ?

And another with the tests...

I only got those two conflicts (after squashing the commits first).

Travis complaining, but not for any of this PR's files:

FILE: /home/travis/build/joomla/joomla-cms/bin/keychain.php
--------------------------------------------------------------------------------
FOUND 3 ERROR(S) AFFECTING 3 LINE(S)
--------------------------------------------------------------------------------
 4 | ERROR | @package tag comment indented incorrectly; expected 5 spaces but
   |       | found 4
 6 | ERROR | @copyright tag comment indented incorrectly; expected 3 spaces but
   |       | found 2
 7 | ERROR | @license tag comment indented incorrectly; expected 5 spaces but
   |       | found 4
--------------------------------------------------------------------------------
UPGRADE TO PHP_CODESNIFFER 2.0 TO FIX ERRORS AUTOMATICALLY
--------------------------------------------------------------------------------

@infograf768 @Bakual @laoneo Tests should be done against 3.7!!

Something about Travis changed recently apparently, it seems to be merging
the changes to the target branch and testing that versus testing from the
branch the PR comes from now.

On Friday, September 23, 2016, Dimitri Grammatikogianni <
notifications@github.com> wrote:

Travis complaining, but not for any of this PR's files:

FILE: /home/travis/build/joomla/joomla-cms/bin/keychain.php

FOUND 3 ERROR(S) AFFECTING 3 LINE(S)

4 | ERROR | @package tag comment indented incorrectly; expected 5 spaces but
| | found 4
6 | ERROR | @copyright tag comment indented incorrectly; expected 3 spaces but
| | found 2
7 | ERROR | @license tag comment indented incorrectly; expected 5 spaces but

| | found 4

UPGRADE TO PHP_CODESNIFFER 2.0 TO FIX ERRORS AUTOMATICALLY

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#11138 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoVULgYpIwNNEbMnbpU4WdT0DpM-kks5qs9zzgaJpZM4JM8Zz
.

@mbabker travis is such a nice guy, always trying hard to entertain us...

Tested OK here.

I remarked something though, which may OR may not be related to this PR.
My Global Config is set to UTC and the user settings for Time Zone is set to Use default.

User creates an article for example:
The start publishing and creation date are pure UTC.

But if one chooses in the calendar today as finish publishing, the date gets the hour of the local machine (France is UTC +2 and my Mac is set such).

@infograf768 that behaviour happens only if you press today button? So if you select a date by clicking inside the calendar the date will be stored normally?

EDIT: Hmm, maybe this line 380 is wrong self.date.setLocalDateOnly('gregorian', new Date());

@dgt41 In fact, I did not click on Today but clicked on the default highlighted date (which was today) in the calendar. But I get the same clicking on Today.

EDit: same when I click on any day.

@infograf768 should work flawlessly now. I converted all the internal methods to UTC MDN ref

@dgt41

I do not get correct results here:
Server Time zone: UTC
User Time zone: Default
Macintosh Date UTC+2 = 10:28

Creating new article and save:
Created date=>6:28
Modified date=>6:28

Finish Publishing (today) through calendar gets 08:31 which is the only one set as UTC BEFORE save and then, after saving the article, becomes 06:31

@infograf768 I've reverted the last commit as it won't work for the php part, but moving the relative code for the timezones filtering seems to fix that problem. Can you confirm?

We come back to the former situation:

@dgt41

@infograf768 I cannot replicate:

After first time save:

After clearing the field (to remove the old time) and selecting today again:

Check that the only field with UTC time is the Modified

Which browser do you use? Which OS?
Which Time Zone are you in?

The Finish publishing date is not filled when saving a new article.
One has to fill voluntarily.

new Date() will always return the local computer date, which explains what I get.

Important Note: we do have the same issue with the old calendar (never remarked it before...)

Please note.

The calendar JavaScript, should NOT care about time zone, it should use (display/set) only user local date/time.

Time will be converted in to UTC before the data saving, in the JForm::filter depend from selected filter SERVER_UTC or USER_UTC.

And before displaying it must be converted back in to user local time, by the calendar field (php part) depend from selected filter SERVER_UTC or USER_UTC.
@dgt41 it is what for switch (strtoupper($filter)){ ... } part is responsible, I guess you need to check that thing ?

@Fedik
The conversion is done OK when displaying the field after save depending on the filter.

The issue is not that imho. It is that new Date() will always return the local computer date.

@infograf768 the new Date() is run on client side, so is normal to have the client's timezone

What is wrong IMHO is what the javascript is delivering to PHP:

• right now is some sting '2016-01-01 00:00:00`
• where in fact it should be this.date.toIsoString() which ALSO GOT TIMEZONE INFO
• then PHP should use datetime($this->value) to get the time zone
• and do some calculations depending on the filter set on the field.

Also this way we don't use JDate and we bypass the strtotime limitation

I wonder why you did some changes in the JFormFieldCalendar field in the switch statement where the cases SERVER_UTC and USER_UTC are handled. Those changes look wrong to me as the code was effectly being used the last 5 years at least and there were no issues to my knowledge.
Changing that may cause issues.

then PHP should use datetime($this->value) to get the time zone

Where are you looking at that value? Because there is some filtering applied after the form is sent (done in JForm::filterField). After that filter, your timezone information is lost for sure.

new Date() will always return the local computer date

It is correct, as I said, javascript should only operate with user local time. It is how it works currently (with old calendar)

@dgt41 Use an user timezone given by Browser not possible without huge BC, and huge code changes in backend part (PHP/SQL)

Changing that may cause issues.

@Bakual I haven't touched the logic of the switch, it's just moved inside the file

After that filter, your timezone information is lost for sure.

I was playing around the other day and the filtering is not nulling the timezone

@Fedik That's the reason I didn't do that already. It needs some big changes and a clearance from PLT (maybe 4.0). But I am just stating that this will be more future proof than what we already have

@Fedik Another way to go around B/C is keep calendar with the code introduced here and introduce another field datetime which will also use the same js. There might need to be some small changes, one param that signifies the usage of datetime as the field name, so the input date from PHP side is taken as UTC compared to the local time delivered in the field calendar

But I am just stating that this will be more future proof than what we already have

I think what we have now it is more "safe", if can say like that ?
If you look around the web, the main recommendation is to save the date in UTC, and ignore the user time zone, but save/display the date depend from the site settings. It how Joomla! work now.

And I am not on the side to changing it ?

the main recommendation is to save the date in UTC

Maybe I wasn't clear: the date will be saved always as UTC. What I am saying is that we could have the correct timezone from javascript delivered to PHP. Beefing up the logic that does the conversion is the proposed change (and also dropping strtotime, which is limited for 32bit versions of PHP, 2038)

I haven't touched the logic of the switch, it's just moved inside the file

I see you reverted the changes back now. ?

I will try to summarize what happens here, (with the old calendar as well as this one).
Joomla and user settings to UTC (i.e. UTC + 0)

1. When saving a new article, we get the correct date, i.e. UTC + 0 for 3 fields:
   Start Publishing
   Created Date
   Modified date

2. When entering a new date through the calendar (or emptying any of the fields above and then entering a new date), we get the Local machine Time (Here it is UTC + 2)

Is there any way to solve this?

You probably will need to pass the user's timezone selection into the
calendar script and all Date objects be set to that timezone.

Note I know jack nor crap about the existing script, or new script, or
what's handling conversion where, but that would be my first step.

On Wednesday, September 28, 2016, infograf768 notifications@github.com
wrote:

I will try to summarize what happens here, (with the old calendar as
well as this one).
Joomla and user settings to UTC (i.e. UTC + 0)

1.

When saving a new article, we get the correct date, i.e. UTC + 0 for 3
fields:
Start Publishing
Created Date
Modified date
2.

When entering a new date through the calendar (or emptying any of the
fields above and then entering a new date), we get the Local machine Time
(Here it is UTC + 2)

Is there any way to solve this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11138 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoZi_NGX5H9Sf0vfydRMKWKgdwFi8ks5qugEsgaJpZM4JM8Zz
.

I think the JavaScript part shouldn't care at all about timezones. JavaScript runs on the client and should always use the clients local time like @fedik explained. I expect the calendar to insert my current time into the form.

PHP then takes care of converting that passed date/time to UTC based either on server or user timezone (depends on formfield attributes).

So this

When entering a new date through the calendar (or emptying any of the fields above and then entering a new date), we get the Local machine Time (Here it is UTC + 2)

is expected behaviour and is just a sideeffect of wrong user settings. If the user sets his timezone correctly to UTC+2, it works flawless.

Then the option is used inconsistently. If the user has to set their
Joomla preference to match their computer IMO there's an issue. Especially
in cases like me where you're traveling, computer timezone changes, and now
your dates are massively off.

I get how the JavaScript Date object works by default. But if it's
yielding inconsistent results and we can address it easily, we should.

On Wednesday, September 28, 2016, Thomas Hunziker notifications@github.com
wrote:

I think the JavaScript part shouldn't care at all about timezones.
JavaScript runs on the client and should always use the clients local time
like @fedik https://github.com/fedik explained. I expect the calendar
to insert my current time into the form.

PHP then takes care of converting that passed date/time to UTC based
either on server or user timezone (depends on formfield attributes).

So this

When entering a new date through the calendar (or emptying any of the
fields above and then entering a new date), we get the Local machine Time
(Here it is UTC + 2)

is expected behaviour and is just a sideeffect of wrong user settings. If
the user sets his timezone correctly to UTC+2, it works flawless.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11138 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoV7a5bSCREfLVd91e10XuK1_yEnYks5quhAUgaJpZM4JM8Zz
.

If you're wroking from different computers, then yes it will be inconsistent. If you're using the same computer it doesn't matter as you probably don't switch the timezone on the device.

For me it would be very counter-intuitive when the JS inserts a time different from the computer time. I'd expect it to be my local time no matter what I set in my settings. But maybe I'm alone with this view.

The way I see it is:
Dates/times should always be saved in the database as pure UTC + 0
Then they should be displayed depending on:
1. The server settings
2. Modified by the Joomla settings : Global or user settings

Does that make sense?

I would not consider the server timezone at all, mostly the server is not in the timezone of the site. But using the Joomla global config tz and if set the user tz makes sense. What many calendar apps do, they show the timezone as read only information.

@laoneo
A non-registered user should be able to see the dates depending or on the server, or on his local machine tz.

@bakual if you travel to another tz most operating systems automatically
change the time on the device. Especially if it is a phone or tablet

@infograf768 Then the global Joomla config timezone should be used IMO, not the one of the server. The computer timezone should also not be used as in Javascript you have only the offset, but not the identifier (http://stackoverflow.com/questions/1091372/getting-the-clients-timezone-in-javascript), this would lead to DST problems, or a library like moment.js can be used which can deal with timezones.

@laoneo I think @infograf768 meant "global Joomla config timezone" (the site timezone) when wrote "server timezone" ?
@infograf768 I am correct?

Dates/times should always be saved in the database as pure UTC + 0
Then they should be displayed depending on:
1. The server settings
2. Modified by the Joomla settings : Global or user settings

@infograf768 this is the current state of the code (php part for that is not touched)

The problem that you are having is kinda weird because in your joomla you have different timezone than the one your computer actually uses. Probably could be solved if we pass the joomla's user timezone to js and do some changes in the calendar script. I think I lean towards the idea of php passing (and receiving) only UTC and all the calculations will be done by the javascript. That of course will be B/C break as the options for the filter will be useless...

We have 2 situations:
1. registered user should see the time depending on her/his defined tz (global if user is set to default).
2. Non registered user should always see the date depending on his local machine tz.
If he is in New-York, he will get UTC -6, in France UTC +2, etc.

Now, this PR, as it is, does not change the behavior of the former calendar, while getting bootstrapped and normalizing custom calendars, which I do consider as a great improvement.
It basically does what @Bakual describes above.

We therefore have 2 solutions:
or we merge it as is for 3.7 (and get all the locales.js from TTs) and improve, if we agree, for later (maybe 4.x)
or we improve it now to reflect the 2 situations above making sure we are B/C.

or we improve it now to reflect the 2 situations above making sure we are B/C

That might be possible with some data attribute (e.g. data-tz="server's timezone (int)") which will be set only for guest users (??). If I understand correctly the problem, that is the thing missing, right?

Also another thing that I came across today: https://github.com/date-fns/date-fns/blob/master/src/format/index.js

Using this code we could have formats like YYYY-MMM-DDDD HH:mm:ss, of course the php part needs to prep_replace all the %$ and convert them to the new format, but I think is way better that the code we have right now. Of course this could be done later one, as the changes won't break something (the only extra thing per language is that an ordinal function needs to be registered in the translation js file).

Anyways back to the main problem: @wilsonge can the PLT make a decision here

That might be possible with some data attribute (e.g. data-tz="server's timezone (int)") which will be set only for guest users (??). If I understand correctly the problem, that is the thing missing, right?

As long as we always save the date in db as UTC + 0 when using the calendar (as the PHP part does), which, as far as I understand, seems to be the main issue.

@bakual if you travel to another tz most operating systems automatically
change the time on the device. Especially if it is a phone or tablet

That may be the case. Lets make an example for what I mean:
An english guy, lets name him Brian goes to a wedding in Greece. At the pool in Greece he is a bit bored and he writes an article and set it to publish for the next day at 10am. Would he expect that time to be the UK time or the Greece one? Personally I would expect it to behave exactly like at home, which means the time I enter is based on my user settings and thus UK time in the case of Brian.

I have never known what it will do in that case which is why
1) I never display the time
2) If i am doing a publish in the future I always run a test first

On 28 September 2016 at 16:41, Thomas Hunziker notifications@github.com
wrote:

@bakual https://github.com/bakual if you travel to another tz most
operating systems automatically
change the time on the device. Especially if it is a phone or tablet

That may be the case. Lets make an example for what I mean:
An english guy, lets name him Brian goes to a wedding in Greece. At the
pool in Greece he is a bit bored and he writes an article and set it to
publish for the next day at 10am. Would he expect that time to be the UK
time or the Greece one? Personally I would expect it to behave exactly like
at home, which means the time I enter is based on my user settings and thus
UK time in the case of Brian.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11138 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8efSjjkM4YrkNsf2viVs5j00jVVyks5qum6XgaJpZM4JM8Zz
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

And, I guess, not all Joomla! users are traveling all the time (especially far away), only few of them ?

@Fedik @Bakual @brianteeman the code should run only for wedding events or it should be more generic?

You might have multiple admins working from multiple timezones. Remember
some countries have lots of tz

If I do not mistake, in php
$tzvariable = $localtime_assoc['tm_hour'] - gmdate("H");

gives the tz for the local machine, independant of Joomla settings.

@infograf768 php runs on the server so that will be the timezone of the server (unless I am missing something here)

There are 4 different type of timezone.

• Machine timezone, means server (ex. linux) time zone. Joomla should not care about it.
• Joomla global timezone: JFactory::getConfig()->get('offset');
• User timezone: JFactory::getUser()->getParam('timezone', JFactory::getConfig()->get('offset')));
• Browser javascript timezone. IIRC currently not supported by joomla.

If user declare and set some timezone in own preference then we should use it.
If user does not declare any timezone or is a guest then we should fallback to joomla global timezone.

Php get date from request, convert it with respect to user preference and save to db as UTC+0.

Off course we may add additional field like timezone and then user can see and change his default timezone to other.

Then:

• php will have to get that timezone value from request and use it instead of user timezone from preference.
• or js will have to convert custom timezone to user timezone from preferences and then send form.

in js we can get the local machine offset as a # of hours vs UTC with

var today = new Date();
var n = today.getTimezoneOffset() * 60;

@dgt41
If I do from line 275 +

var n = today.getTimezoneOffset() * 60;
        if (isNaN(y)) y = today.getFullYear();
        if (isNaN(m)) m = today.getMonth();
        if (isNaN(d)) d = today.getDate();
        if (isNaN(hr)) hr = today.getHours() + n;
[...}

When saving the article, I get:

Saving again => no change. I.e. in db I do have UTC +0 and display is correct i.e. UTC +1 (london)

But if I then enter today's value (or any other date) in Finish Publishing, I get

I.e. The start Publishing date is now displayed as UTC -7 and is indeed set to that time in the db. Wrong...

Maybe this test can help solving the issue.

@infograf768 the logic should be a little more complicated than that as there are timezones like +3:30 (h:m) (PR) or +4:30 AF and +12:45 for New Zealand.
The work flow should be (IMHO):
from php to js the value is UTC
from js to html the value is UTC + timezone (display value in the input box + calendar values)
from js to php the value is UTC

This way, no matter what, db has the UTC value and user has the time in whatever their computer timezone is set to (mind that most OS have an option that the timezone is automatically adjusted).
Another benefit we can safely drop the filters server_utc and user_utc, because in such case (at least for the calendar) would be useless.
Thoughts?

If anything, you could only do that in 4.0 as it would mean a B/C break to the current system. Remember the field class is likely extended by 3rd parties and the calendar itself (using JHtml) is used without the formfield. And there are even cases where the date actually shouldn't be converted at all (eg a date of birth field or historical events).
But then I don't think it is the right approach and it will fail horribly if JS is disabled for whatever reason.
Also you will still need to calculate the timezone difference using PHP when a date is displayed without the calendar, so you would sometimes do it in PHP and sometimes in JS which certainly will give you troubles down the road.

I think like next,
we build a Rocket or DateTime picker?

Let's split the things,
for now would be cool just finish the DateTime picker, and keep old timezone behavior.
And the discussion about changing the time zone behavior let's move into another task.

@Fedik this is Rocket science ?

Just to recap: as is the code right now is 100% B/C with the old one, same behaviour, so we stay with that, or there is something that is handled different and we have to adapt to the old behaviour? (I am really confused...)

or there is something that is handled different

I had no time to check it ?
I try to test it in next weekend

#11138 (comment)
for me, as i wrote above, this b/c and works fine. we can wait to reconsider the tz

I have tested this item ✅ successfully on e73d291

While testing the localised format today I noticed that the calendar changes the format back to YYYY-MM-DD before sending. That would be wrong and would be a B/C break imho because if the developer sets the format to something else than YYYY-MM-DD he expects it to come back in his specified format as well, and not in YYYY-MM-DD. He may have code dealing with his specific format in place.
The date should be sent exactly in the form it was entered like it is sent today with the current calendar.

For example it would break PR #12102

@Bakual I will change that to match the old behavior. Probably tomorrow....

Can someone re open this, Too many drinks...

So with latest update:

• revert the deletion of the old js and css files (b/c)
• given format is used always (b/c)

@Bakual I think this is what you meant

Should be, but can't test the next two weeks ?

I have tested Jalali Calendar, every thing is ok, the only thing that we have to adjust is css ( check the green triangle)

Persian TT Coordinator

This does not work in IE8 or 9. Please check the console log errors

On the Article Edit page in IE8, it also prevents the tabs (options, publishing, permissions, etc) from showing.

@C-Lodder you need to uncomment in the layout calendar.php

// Load polyfills for older IE
//JHtml::_('behavior.polyfill', array('event', 'classlist'), 'lte IE 11');

I am not sure if the relevant PR is merged tho, that's why I commented it out

the polyfill PR is merged in 3.7.x (075a14b), but it needs another PR (#11289) that is not merged yet in 3.7.x (needs tests ...)

so if you add the polyfill code it will not have effect until #11289 is tested and merged in 3.7.x

@andrepereiradasilva yeah I know, that's why I had commented out that line!
@C-Lodder thanks

So after some minor changes the calendar looks like:

Nice. No idea where that green triangle is coming from :/

Didn't get anything on FF, so could be a webkit thing.

No idea where that green triangle is coming from :/

I guess it is the marker for the current date? As we have today the 07.10.2016?

@C-Lodder the green triangle is signifying today (class today)

@C-Lodder I do get the green triangle in all browsers (no IE here):

Would it not be better to add a blue or green border around the date rather than using a triangle?

Would it not be better to add a blue or green border around the date rather than using a triangle?

It's a matter of taste, I just throw some css to show that there is a class for that. UI experts, like you, can make the most of it, I guess...

tried to test, and found strange thing:

Article Start Publishing
When I set time manually (without calendar) to 10:00 (example) the script reset it on submit to initial value, each time
and in popup there no Time select,

but in Module Start Publishing I can do the same without problem

@Fedik I think I changed the article.xml on purpose or by mistake, don't remember anymore, anyway just revert the extra params in that file and should work fine...

EDIT showtime="false" should be either deleted or turned to true

Do you want to solve conflicts here and fix that bug fedik mentioned ;)

@wilsonge since we have the polyfills available now in 3.7 I will add that for IE8 and undo all the extra things added to the filed (I've added them in the first place so people will contact tests easier).
Also fix the conflict
This will require some tests on IE8

@infograf768 @wilsonge updated

I have tested this item ✅ successfully on 943286f

As custom fields was merged, time to introduce the new parameters in custom fields for the calendar type. What are the new parameters?

@laoneo I've documented them in the Jlayout, but here is the list:

 /**
 * Calendar Specific

 * @var   string   $minYear         The minimum year, that will be subtracted/added to current year
 * @var   string   $maxYear         The maximum year, that will be subtracted/added to current year
 * @var   integer  $todaybutton     The today button
 * @var   integer  $weeknumbers     The week numbers display
 * @var   integer  $showtime        The time selector display
 * @var   integer  $filltable       The previous/next month filling
 * @var   integer  $timeformat      The time format 24/12h
 * @var   integer  $singleheader    Display different header row for month/year

 */

@laoneo this is not yet merged!

Removed some hardcoded styles

I have tested this item ✅ successfully on a7105c0

Yes!!

When I apply the patch using the patch tester I get a some errors.

Notice: Array to string conversion in Z:\webserver\demo\libraries\joomla\document\renderer\html\head.php on line 144
Notice: Array to string conversion in Z:\webserver\demo\libraries\joomla\document\renderer\html\head.php on line 144
Notice: Array to string conversion in Z:\webserver\demo\libraries\joomla\document\renderer\html\head.php on line 149
Notice: Array to string conversion in Z:\webserver\demo\libraries\joomla\document\renderer\html\head.php on line 144

Also the J! interface is messed up even when error reporting is set to none. Looks like all dropdowns are messed up...
I added a screenhot.

@RickR2H That indicates another possible B/C problem:
These commands

JHtml::_('script', $localesPath, false, true, false, false, true);
JHtml::_('script', $helperPath, false, true, false, false, true);
JHtml::_('script', 'system/fields/calendar-vanilla.min.js', false, true, false, false, true);
JHtml::_('stylesheet', 'system/fields/calendar-vanilla' . $cssFileExt, array(), true);

create notifications?

@andrepereiradasilva some input here?

It may also be that patchtester fails on such a PR.

Patchtester will tell you if it didn't apply the patch

It may apply the patch partially as we have seen in some other cases...

@dgt41
Although I do not get these errors, I wonder about this:
When clicking on a date, it does not close the calendar. I have to hit Enter to close it. Is that new?

@infograf768 that's correct, for the calendar that displays the dropdowns for the hour and minutes selections. If you are using just date then selecting a date will close the calendar. For the calendar that also displays time we cannot close the calendar because the user needs to select the time (probably after selecting the date), so either use the close button or click outside of the calendar.

It may apply the patch partially as we have seen in some other cases...

Patch tester does not "patch", it replaces files from the remote branch, as has been explained in the past. It also used to not be able to handle binary files, and told you when it hit that case. That was fixed months ago.

There is nothing in this PR patch tester will fail over. You just must have a current development version of Joomla for it to work right because of how files are replaced; applying this onto a 3.6.4 install will cause problems.

Most people here can test bigger PRs (that modify many files), without the patchtester

Much faster and safer is:
(if your local installation is a git repository)

git fetch origin pull/11138/head:new_datepicker
git checkout new_datepicker

then test

and then checkout staging and delete the new branch that you had created

git checkout staging
git branch -D new_datepicker

@ggppdk or for those that are not familiar with git commands:
download https://github.com/dgt41/joomla-cms/archive/+FieldCalendarNew.zip and then extract the zip file and install joomla as usual...

@dgt41 Why closing?

• Lack of interest:

Hmm, where does that screenshot come from?
This PR seemed like it got a lot of attention and still being a work in progress. Latest commits are only 10 days old.

Lack of interest ??
how many people have replied to this PR ?

This PR means some more work for me to update my existing code,
since i am using the old calendar directly,

but you have made a lot and good work,
i would like this work not to go wasted

Even if does not make into J3.7 it is great addition for J4

PLEASE, do NOT close this. It hsould go into 3.7
I tested OK. We need one more tester.
We already have the meta in language xml

Set to "open" on behalf of @infograf768 by The JTracker Application at issues.joomla.org/joomla-cms/11138

Trying to set back to pending

I have tested this item ✅ successfully on a7105c0

@dgt41 Please see this one through, I think you have done an amazing job so far. There is one issue I still see, see this screenshot:

To see this you need to enable the User Profile plugin and after that edit a user. I think if this issue is fixed we are ready for RTC.

@dgt41 - You can use JVisible that I added here to determine whether or not the element is fully visible in the viewport.

@C-Lodder thanks, but I will pass. Calendar is vanilla so I won't add jQuery dependency just to flip the container if out of viewing area ?

At some point I had some code to take care of that:

        // Move the calendar to top position if it doesn't fit below
        if ((window.innerHeight + window.scrollY) < this.element.getBoundingClientRect().bottom +20) {
            this.element.style.top = window.innerHeight + window.scrollY - this.element.getBoundingClientRect().bottom + "px";
        }

So i need some time to adjust that...

You can vanilarise it :)

If you're really going to duplicate the logic, put it in the core JS somewhere, make it JS agnostic to keep you happy, and deprecate/drop the template specific function instead of us having duplicate code doing the same damn thing all over the place. Otherwise just use the function that already exists and cope with it.

@mbabker - yup, that too.

@mbabker @C-Lodder I have no idea what's the usage of that function, but I manage to do the logic and the required adjustments in 3 lines. The function is way bigger and only covers half of it (is it completely viewable). So DRY is not the way to copy that code here, maybe the other way around?

It's used for the top menu 3rd level dropdown. If the 3rd level goes below the viewport, the position is adjusted.

@roland-d I restored the code that was missed somewhere in the 135 commits and looks promising:

Looks good indeed, will give it a test possibly tonight my time.

I have tested this item ✅ successfully on a7105c0

The calendar aligns correctly, date and time show up as expected. A date-time format that is set is respected as well.

Set to RTC

@roland-d can you remove RTC till we get some tests with IE8. I prefer doing fixes at this point...

Removed RTC for testing on IE8

Check the installation language file where we have a multiple messages not
to translate the name of the installation folder. 50% still translate it :(

On 17 Nov 2016 9:34 p.m., "andrepereiradasilva" notifications@github.com
wrote:

@andrepereiradasilva commented on this pull request.

In libraries/joomla/language/language.php
#11138:

• *
• * @return string The calendar type.
• *
• * @since DEPLOY_VERSION
• */
• public function getCalendar()
• {
• if (isset($this->metadata['calendar']))
• {
• return $this->metadata['calendar'];
• }
• else
• {
• return 'gregorian';
• }
• }

still translators need to change it to jalali if needed (at least farsi i
think)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11138, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8eF1DESpa_gJli5zeSb3aJDd_2Arks5q_MhRgaJpZM4JM8Zz
.

@dgt41 So I tried testing this on IE8 but it looks like more stuff is broken on IE8, for example the tabs we have they don't render. Instead of me having to try and explain everything, perhaps you can take a look yourself. Microsoft offers Virtual Machines for free here: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

Let me know if there is anything else I can do.

@roland-d did I've opened pandora's box again? ?
Thanks for the link I'm not at my place for the weekend so probably Monday, I'll try to figure what can be patched...

@dgt41 You seem to have a skill for that ;) Enjoy your weekend.

@roland-d So there are few problems with IE8, the calendar's problems will be fixed in the next commit (chosen related and a missing polyfill)

Make sure that #12943 is applied as well

I've merged #12943 so if you want to rebase this onto staging should be all good :)

OK scrap that managed to do it myself :)