Search

As brendo said this is a conflict between the calendar overlay and Date and Time field. Version 1.3dev should fix it.

This is how it should look like:

Date and Time

Attachments:
datetime.png

Nils,

What testing needs to be done to get 1.3 out of dev and pushed as a release?

Well, there a constantly issues with the relative dates (today, tomorrow etc.) – in general and in connection with the German localisation. So this is about bug hunting and bug hunting.

There is another reason why I haven’t released 1.3 yet: As I mentioned in another thread I like to create an unified interface plugin for both Date and Time and Mediathek as it takes to much time to support both extensions separately. Time is a general problem – holidays are over and I have a lot of work to do at my day job this month.

Well, there a constantly issues with the relative dates (today, tomorrow etc.) – in general and in connection with the German localisation. So this is about bug hunting and bug hunting.

If you would care to post this on Github/Symphony I can take a look, as I’ve got some free time for a few days next week and would love to help where I can.

Could the unified interface possibly wait till 1.4? There’s a few bugfixes in 1.3 that are pretty handy and would be good to push out the door ASAP IMO.

bredo, I just pushed my current code base to GitHub. It would be great if you could just test it thoroughly. There is – from time to time – a problem with the selection of the current date (today). Maybe this is related to some problems in dateJS framework which is sometimes messing up dates like 2009/07/01 (is this January or July?!).

Thanks for your help.

Please note

Using this extension in conjunction with the Localisation Manager and setting the language of an author to something else but system standard may break the Date and Time field. For some reasons yet to be fully understood the calendar will show all dates as 01 January 1970. Changing the author’s language back to system standard will fix this issue.

Date and Time updated to version 1.3 on 15th of January 2010

  • Added German localisation, improved date handling.
  • Fixed a lot of bugs and overall improvements by brendo (thanks!)

I’ve posted a bug report in the issue tracker.

Basically, the Date and Time field causes an error if empty when you submit an entry.

I’ll have a look at the bug report but this is not a bug, it’s an intended feature.

Is there any way to get around this?

Question is: How would you expect the extension to behave?

Honestly? If the field was empty and I hadn’t marked it as required I’d expect it to just be empty.

The intended use I have is for a counseling service’s website I’m creating. The site sometimes has set dates for workshops and similar but other times it does not. In the cases when there aren’t any they’ll just be leaving the field empty.

What happens now if they do that is they get a Symphony fatal database error but the empty entry is still created.

Ah, I’m sorry, I was mislead by your statement that the “Date and Time field causes an error if empty when you submit an entry”. Thought of a Symphony error at the top of the screen for empty/missing field.

Should have read your bug report properly - it’s a bug then. The field is intended throw an error for empty fields though but this should just be a highlight of the empty field. Will have a look at it.

Problem is: the field will always try to save a date to the data base, so “empty” will always correspond to 0000-00-00 00:00:00 or 1970-01-01 00:00:00 (which is not what you are after).

Not what I’m after but a viable work-around.

When I work my XSLT I could look for year 0000 and if so display a message instead. This is fine as what I was intending to do was simply look for an empty entry.

Though, I should point out that if you do enter 0000-00-00 00:00 then the field displays 31 December 1969, 19:00 instead upon saving.

Hmm. I think I just found another bug relating to editing saved entries as well. Let me poke around a bit more with that, I might have another bug for you. (Sorry!)

EDIT: Yep, bug confirmed and posted in the bug tracker.

Question: Which behaviour would you expect in case of a blank date and time field?

  1. No saved date and time at all (this will result in a missing date and time field in the XML).
  2. A saved date and time of 0000-00-00 00:00:00 in the data base which could be returned as an empty element in the XML (e. g. <date-and-time />)

I might have another bug for you. (Sorry!)

No problem.

Question: Which behaviour would you expect in case of a blank date and time field?

  1. No saved date and time at all (this will result in a missing date and time field in the XML).
  2. A saved date and time of 0000-00-00 00:00:00 in the data base which could be returned as an empty element in the XML (e. g. )

From a technical standpoint either works fine for me. I’m more thinking about my clients who aren’t techno-savvy. To them, putting in a lot of zeros might be confusing—I should mention that one asked me how to rename a file in Windows, so you see how I can think that.

In the actual field as displayed to the user in Symphony I would prefer it to be empty. In the datasource whether it shows up as a lot of zeros or an empty element isn’t an issue for me as I can work with either.

In an ideal world what I would most prefer is that if the field is empty the only time it would send an error is if I told it the field was required. Otherwise it would remain empty and deal with displaying in the datasource however you thought was best.

To them, putting in a lot of zeros might be confusing—I should mention that one asked me how to rename a file in Windows, so you see how I can think that.

I don’t think the users should have to enter a special notation. My question focusses on the extension itself: how should the extension react, if a date and time field is completely empty on saving.

Ideally, it would depend.

If, when creating the section, I checked the box to say the Date and Time field was required when they clicked to save it the field was empty it would react the same way any other empty required field would in telling the users they need to put something in.

If I had not marked it as required when creation the section I would expect it to save the page as usual. From a user’s perspective it would be less confusing if the field stayed empty instead of populating with a bunch of zeros but if it’s easier and more stable for the system to have those zeros than it’s of little consequence.

Doug, can you please try the changes in the integration branch of the Date and Time repository on GitHub and see if they solve your first problem?

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details