and i can´t see an override option

as of now, it is not there.

I believe, that the existing calendar field is an early version and will still receive quite some enhancements (like the very important** entry field** for the date)

Knowing Sergey, I am sure that he will find a way to incorporate all feature request (as long as they make sense) to produce an outstanding solution.

to get an idea about the date picker, see the mootools date picker demo page

http://aryweb.nl/projects/mootools-datepicker/Test/

I have seen a better jQuery version

I believe the philosophy of cobalt is to stay as close as possible to the Joomla environment (where mootools is the JS framework), therefore the chosen solution might have been the best option for the cobalt calendar field.

I have seen a better jQuery version

the time is an input?!?

See screen shot ... the mouse wheel can be used for time input as well ... :D

What about Tablets and note/netbooks etc.

On notebooks, just use the rightmost area of your touchpad to use the mouse scroll emulation ... (it works at least on my laptop - Win7) ...

too much "Gefrickel" :-) (Do you know an english term for "Gefrickel" ?!

hmm .. i would use the term "hassle" ... too much hassle ...

--> to cause annoyance or trouble to (someone);

http://www.thefreedictionary.com/hassle

anyway, lets see how the datetime field will evolve in the next weeks ... after some bug fixing and enhancements (maybe based on your suggestions), this filed will be much more powerful than the old "Terix Calendar" for Resources 1.5.x .. just alone because of the filtering and date range functionality.

We will certainly incorparte all your suggestions that will be possible to implements without changing source JS library.

Regarding my first post and feature listing... and besides the core date override options:

Wouldn't it make sense to have similar date input and customization for Cobalt core dates? I think layout and UI are not tied to any J! system stuff, right? So, why not improve it?

1. Could make an override by date/time field obsolete. (almost!)

2. way better user-experience (no end-user understands the system default stuff)

Anyway, i still think the override feature is very important. Because field placement and layout is easier for submission. More flexible, i.e. I can put important date/time inputs in a prominent place etc.

Wouldn't it make sense to have similar date input and customization for Cobalt core dates? I think layout and UI are not tied to any J! system stuff, right? So, why not improve it?

Will be there soon.

Wouldn't it make sense to have similar date input and customization for Cobalt core dates? I think layout and UI are not tied to any J! system stuff, right? So, why not improve it?

1. Could make an override by date/time field obsolete. (almost!)

Please explain

Wouldn't it make sense to have similar date input and customization for Cobalt core dates? I think layout and UI are not tied to any J! system stuff, right? So, why not improve it?

1. Could make an override by date/time field obsolete. (almost!)

2. way better user-experience (no end-user understands the system default stuff)

Please explain

Override scheduled.

By the way why you say order will not work? If you make field orderable it should work. And in calendar list template we will make possibility to show calendar based on datetime field.

Agree. Will be there in next release.

Date & Time field requests:

...

very simple input options

(selectbox, no JS or interactivity)

Still longing for simple selects ;-)

Unfortunately, it allows NO FUTURE dates beyond the current year!? Other UX cosmetics are in my previous comments.

Have to check it again...

Was it already implemented?

Yes, I do not remember. It was 6 mont ago :)

Unfortunately, it allows NO FUTURE dates beyond the current year!? Other UX cosmetics are in my previous comments.

Done.

Unfortunately, it allows NO FUTURE dates beyond the current year!? Other UX cosmetics are in my previous comments.

One more thing: Selects would need a text before/after on input. At least the time... For example: 12:00 o'clock ... 12:00 Uhr

Selects have default labels inside. So, my request is not completely integrated on submission. A minor issue. Not important or crucial.

Current visual appearance:

BTW, input mask in text input template works great.

Additional request for overrides:

Usecase is an Event entry. Usually with start and end-dates. Usually you have to set the core EXpire date to get rid of old entries. So, core field overrides come into play. So far, so good...

But there is one issue in real-world situations, because users tend to enter "events" that are not really related to "real" dates: i.e. a user offers a 3-day workshop at weekends... but this occurs serveral times... lazy users just enter a loooong date range, and give additional time details in the description text.

This results in "permanent" and sticky entries, because there are no proper EXpire dates set. The user selects a very long timeframe, and does not enter single/multiple event dates.

**Possible solution:

**- take the START date as usual - take an END date for display only! - Set a hidden EXpire date!

The hidden EXpire date is actually the STARTdate + Nth hour/day/week/month

Result: The entry can be excluded as soon as possible from the listing. No matter, if the user has entered a very far end-date. In general, an event can be marked as expired, shortly after the beginning.

**Requirement for field parameters:

**- a 2nd field to select and override (currently, there is only one) - Counting/Adding time on the field to override (so, default can be set to an automatic future date from start)

Thanks for listening.

PS: Would also appreciate it in ME Resources TERIX date field ;-)

I think it is possible.

1. You add start date field and alter create date

2. You add end date field but not alter expire date

3. Set in parameter for records automatically to expire in 10 days.

1) This is easily fixed :). We will just auto-expire always from the creation date. Because it make more sense to me.

2) Not necessarily. You may turn off prolong ability for user and use it just to wipe articles away after certain amount of days.

Would that do the thing?

1) This is easily fixed . We will just auto-expire always from the creation date. Because it make more sense to me.

I remember, my own ME-Resources debate about available core-dates. Unfortunately, ME-Resources had no initial create-date ;-) Actually, its just one publish-up date.

Can´t remember it at the moment...

do you store the FIRST INITIAL creation date in Cobalt? How do you call it? It looks like you still call the PUBLISH-UP date CREATION-DATE ?! Also in backend. Thats a bit confusing.

Using it instead of NOW for auto-expire? Not sure if this is of help.

An Event gets a PUBLISH-UP date. (Cobalts core create-date, hence the name. Actually not correct)

1) This is easily fixed . We will just auto-expire always from the creation date. Because it make more sense to me.

2) Not necessarily. You may turn off prolong ability for user and use it just to wipe articles away after certain amount of days.

But how to get the expired articles back? If the user wants to edit and re-publish it.

(At least in Resources, this was not possible due to the "bug" i mentioned in #3.

But how to get the expired articles back? If the user wants to edit and re-publish it.

(At least in Resources, this was not possible due to the "bug" i mentioned in #3.

There is "expired" user menu item where user can see all his expired articles.

Additional request for overrides:

Usecase is an Event entry. Usually with start and end-dates. Usually you have to set the core EXpire date to get rid of old entries. So, core field overrides come into play. So far, so good...

But there is one issue in real-world situations, because users tend to enter "events" that are not really related to "real" dates: i.e. a user offers a 3-day workshop at weekends... but this occurs serveral times... lazy users just enter a loooong date range, and give additional time details in the description text.

This results in "permanent" and sticky entries, because there are no proper EXpire dates set. The user selects a very long timeframe, and does not enter single/multiple event dates.

Possible solution:

• take the START date as usual

• take an END date for display only!

• Set a hidden EXpire date!

The hidden EXpire date is actually the STARTdate + Nth hour/day/week/month

Result: The entry can be excluded as soon as possible from the listing. No matter, if the user has entered a very far end-date. In general, an event can be marked as expired, shortly after the beginning.

Requirement for field parameters:

• a 2nd field to select and override (currently, there is only one)

• Counting/Adding time on the field to override (so, default can be set to an automatic future date from start)

Thanks for listening.

PS: Would also appreciate it in ME Resources TERIX date field

Just wanted to say thank you for integrating my ideas and parameters. On first sight, everything is there. Just noticed the new parameters in C8 Date & Time field. Unfortunately, I had no occasion for real-world tests, yet. But very soon.