17 replies to this topic

[ryan]

The current core date/time fieldtype/inputfield in ProcessWire has been a little weak, and there are some issues when it comes to using the datepicker. I've been working on fixing all of these and really upgrading the datetime fieldtype and inputfield to be much stronger. However, I need some help testing before a commit to the core source. I would just put it on a dev branch, but know that not many people will try it that way, so figured this would be better to post here.

The file is attached. To install, you'd replace the existing files...

/wire/modules/Fieldtype/FieldtypeDatetime.module
/wire/modules/Inputfield/InputfieldDatetime/ (entire directory)

...with the new ones here:  Datetime1.zip   22.08K   83 downloads

Here's what's new:

• You can now select from predefined date and/or time formats, rather than having to manually construct a PHP date format (though you can still do that too if you want to).
• It converts your date format to the equivalent javascript format, so when you select a date from the datepicker, it stays in the right format rather than changing to a YYYY-MM-DD format like that old one did.
• No more conversion issues with day-first vs. month-first dates and the datepicker.
• There is now a time picker too! If you opt to include a time component, the datepicker will include a timepicker.
• You can now choose when you want your datepicker to appear: on click (as before), on focus (new), or inline (new, always visible).
• You can now optionally specify alternate date/time output and input formats on a per-language basis. So if you need month-first dates for US users, and day-first dates for European users, no problem.
• For the date output format, you can use PHP strftime() codes if you want to. This enables you to have one date format that outputs language-specific/localized month or day names. Though if you don't need to output localized month/day names, then it's better to stick with the default date formats.

If anyone gets a chance to try it, please let me know how it works for you and if you run into any issues. There is a lot of new and somewhat complex code in here, so it needs a good testing. I've been testing here, but know with something like this there are some scenarios I could miss. Once we've confirmed all is stable, I'll commit this to the core.

Thanks,
Ryan

Date/time picker example:


Fieldtype configuration example:


Inputfield configuration example:

[netcarver]

Hi Ryan,

I'm trying this out now and it looks nice -- thank you!

I've created a date of birth field using this field-type and added it to a template, setting it up to show on button press. However, I've hit a few issues with it so far...

• The year shown in the picker seems to be limited to this year +/- 10 years -- which is way too limited for a d.o.b field. I can't see any way to change that range, nor can I change it from the pop-up picker. I can change it by editing the date manually but that kind of negates the use of the picker.
• Attempting to save dates on, or prior to, the Unix epoch (01/01/70) fail silently when using the 04/08/12 input format and lead to a blank value in the field. As this doesn't happen in some of the other formats it doesn't seem to be a limit of the storage. If this is a consequence of a limit on the two-digit year input then this probably needs to raise a warning in the UI.
• The list of choices for the input and output date format currently use April 8th (in whatever format.) I'd suggest using an example date with a day number > 12 so that it is immediately obvious in the list which part of the date is the day. Using April 8th (04/08) is still ambiguous in some of those formats. Using something like April 24th would remove the ambiguity (04/24 or 24/04).

More to come as I find it.

Once again, thank you for working on this.

Edited to add: Just a thought, but having this as a dev/experimental/nv branch would actually be useful (for me, at least, and maybe for other git users here too.)

Edited by netcarver, 29 April 2012 - 03:24 AM.

[ryan]

Thanks for the feedback Netcarver! I think the jQuery UI standard for stretching groups of years is to select the first/last year, and then it should extend the list. I'm on mobile now, so can't easily confirm yet, but I think that's how it works if I recall correctly.

I will try with dates before unix epoch. I haven't tried before 1970 yet, but should support them with negative numbers, but not positive about the jQuery stuff and how far their support goes. Good find--I will test Monday.

As for April 8th--I needed a date that would demonstrate the difference between zero padded vs. not. Anything above 9 prevents me from doing that. Plus 4/8 is my daughter's birthday. It's a date that worked for both months and days in leading zeros vs not. Still I agree about some ambiguity there, but at least all the info is there to figure it out. We may have to ultimately show two date samples to maximize clarity.

Thanks again for helping me to test this!

[Marty Walker]

Hi Ryan,

From my limited testing it works great. Thanks!

Regards
Marty

[netcarver]

Thanks for the feedback Netcarver! I think the jQuery UI standard for stretching groups of years is to select the first/last year, and then it should extend the list.

Yes, that seems to work. Would be nice if we could specify the year range to appear in that picker (as sometimes year +/- 10 is too big a range, and sometimes too small) -- but perhaps I'm just being picky.

I will try with dates before unix epoch. I haven't tried before 1970 yet, but should support them with negative numbers, but not positive about the jQuery stuff and how far their support goes. Good find--I will test Monday.

Also having issues with the unix timestamp, but I may be using this wrong. For this, I've set my timezone to Europe/London and we are on daylight saving time here.

If I manually set the field to 0 and save, it gets adjusted to -3600 on save, even though I wanted it to be zero -- presumably an adjustment for DST. Anyway, I know there is an adjustment of -3600 being made on this field when saved directly. Ok so far.

If I now open the picker and take the year back to 1970, the month back to Jan and the day back to 2, I'd expect to see a timestamp of (24*3600) - 3600 or 82,800 when I close the picker. Instead, I get 82,800,000 on close -- so it looks like the timestamp coming from the picker is at millisecond resolution. Finally, when I then save the page with 82800000 it converts to -3600 on reload.

As for April 8th--I needed a date that would demonstrate the difference between zero padded vs. not. Anything above 9 prevents me from doing that. Plus 4/8 is my daughter's birthday. It's a date that worked for both months and days in leading zeros vs not. Still I agree about some ambiguity there, but at least all the info is there to figure it out. We may have to ultimately show two date samples to maximize clarity.

Ah, sounds like a great day! And this is a really minor suggestion anyway so please treat it as such. However, I do think that just having the day > 12 will still allow folks to see leading vs non-leading zeroes in the formats as the use of April as your month will give you either 4 or 04 so you can still see it. Only problem would arise if you can separately set the leading zeroes on both the day and month field -- but that doesn't seem to be the case from the formats in the list.

Thanks Ryan.

[ryan]

Thanks for the testing netcarver and stillmoving design.

Would be nice if we could specify the year range to appear in that picker (as sometimes year +/- 10 is too big a range, and sometimes too small) -- but perhaps I'm just being picky.

Looks like I can set this with the jQuery UI datepicker 'yearRange' option. Though I'm wary about getting too many configuration options with the field, unless it's something everyone will use. Good point though, this may be one to have...

However, if I now open the picker and take the year back to 1970, the month back to Jan and the day back to 2, I'd expect to see a timestamp of (24*3600) - 3600 or 82,800 when I close the picker. Instead, I get 82,800,000 on close -- so it looks like the timestamp coming from the picker is at millisecond resolution. Finally, when I then save the page with 82800000 it converts to -3600 on reload.

JS/jQuery datepicker is working with the timestamp in seconds * 1000, whereas PHP isn't. I did the conversion on the front-end (passing value in ms), but neglected to on the submitted value. So that's a bug-- thanks for finding it. But it brings up something else. Rather than adding code for this exception, I'm really wondering if there's any point in having a unix timestamp for this field. After all, the unix timestamp is always available since PW keeps it in memory as a timestamp regardless of what date format you choose... converting from timestamp to formatted date is part of runtime output formatting. And a timestamp is always acceptable as input from the API. So the whole purpose of the date/time format and date/time picker is so that you don't have to see/use a timestamp. As a result, I'm thinking perhaps I should remove the timestamp option, unless anyone can think of a reason to keep it. The question is why I put it there in the first place.

[yellowled]

Not sure if you still need extra confirmation on this, but it works fine in Geman for me with the sole exception that I still need to use setlocale to get localized weekday names. But I guess that's due to strftime's lack of a local version of the weekday names.

[ryan]

This is true that strftime() requires a setlocale() call in order to determine what language to use for things like month and weekday names. But this of course is the main reason one would use strftime() because it can do this (PHP's date function can't do this). ProcessWire will call setlocale() for you if the locale is defined with the language pack. In your language pack, you can look in the translation file for /wire/modules/LanguageSupport/LanguageSupport.module, and it should be one of the translation lines in there. Depending on your server, the locale may need to be adjusted to one that is installed in your server. You can type this to get a list of all locales installed on your server (in the unix shell):

locale -a

[yellowled]

ProcessWire will call setlocale() for you if the locale is defined with the language pack. In your language pack, you can look in the translation file for /wire/modules/LanguageSupport/LanguageSupport.module, and it should be one of the translation lines in there.

Doesn't look like it for the German language pack. I grepped across all (installed) files in /wire/modules/LanguageSupport/, which gives me this in LanguageSupport.module:

$locale = $this->_('C'); // Value to pass to PHP's setlocale(LC_ALL, 'value') function when initializing this language
// Default is 'C'. Specify '0' to skip the setlocale() call (and carry on system default).
if($locale != '0') setlocale(LC_ALL, $locale);

But, and I remember reading something about this in another thread regarding the datetime field, I'm on a Ubuntu machine, and apparently, Ubuntu uses some non-standard localeds. Setting it to "de_DE" for instance does not work, it has to be set to "de_DE.utf8" (which looks weird to begin with). Could be related to the fact that this is Ubuntu desktop, not server.

[tinacious]

Hi everyone. How do I get ProcessWire to echo the date? I've created a new field using the datepicker called pub_date. When I use $page->pub_date nothing shows. Is there more to it than this? Thanks.

[SiNNuT]

That should work but you really don't give a lot to go on here. Have you you checked that you're pub_date field actually contains values? If you can't figure it out yourself you should provide more info, possibly a relevant code sample.

[ryan]

Also make sure you are doing:

echo $page->pub_date;

rather than just:

$page->pub_date;

[apeisa]

Does anyone know how jQuery UI datepicker can be configured to use other languages than English? There ain't no language code selection like there is in TinyMCE field yet, so not sure if that is possible yet.

BTW: That solution that TinyMCE has is perfect for us, since we only need to support Finnish in backend. But people who need multiple Admin languages do have a need to match Inputfield language with the language preference the current user has. Not sure what would be best way to approach that. Just ignore that, I don't make any sense. Since that setting is set on lang editing interface, it is always lang specific setting, not global.

[Soma]

jQ ui datepicker has languages http://jqueryui.com/...calization.html
It would be easy to just include the required [lang].js depending on admin language.

[ryan]

I wasn't exactly sure how to do this, and if it'll work given that we're using a combo date+time picker, but I need to look into this further as soon as there is time.

[Pete]

Just a quick one, is this part of the core yet or is it due for inclusion in 2.3?

Just curious, but I've not had a look at the latest build yet and I'm going from my mobile so can't test right now.

[apeisa]

It's there already. The datetime field enchantments, not the lang support for it.

[Pete]

Cool - finally back at my PC now so I can play with this!