A filter that changes a preparsed date from [Ultimate Feedparser](http://www.feedparser.org/) to a regular datetime instance. Now you can -for example- pass a feed parsed by feedparser to a template and do this: {% for item in feed.entries %} Title: {{ item.title }}<br /> Date: {{ item.updated_parsed|feedparsed|date:"Y-m-d" }} {% endfor %}
This widget will produce a select box with the range of dates that you input. **Usage:** `widget=SelectDateWidget('2010-12-15', '2010-12-20')` **Output:** `<select> <option value="2010-12-15">Wed January 01, 2010</option> <option value="2010-12-16">Thu January 02, 2010</option> <option value="2010-12-17">Fri January 03, 2010</option> <option value="2010-12-18">Sat January 04, 2010</option> <option value="2010-12-19">Sun January 05, 2010</option> <option value="2010-12-20">Mon January 06, 2010</option> </select>`
A simple Python function that converts a Python datetime formatting string to its nearest PHP equivalent. Python and PHP use different format string conventions when specifying datetime formats: * Python: [https://docs.python.org/2/library/time.html#time.strftime](https://docs.python.org/2/library/time.html#time.strftime) * PHP: [http://php.net/manual/en/function.date.php](http://php.net/manual/en/function.date.php) Working with Django the Date, Time and DateTime widgets all use Python format strings as stored in: * django.conf.global_settings.DATE_INPUT_FORMATS * django.conf.global_settings.TIME_INPUT_FORMATS * django.conf.global_settings.DATETIME_INPUT_FORMATS but if you want to use a datetime widget like the datetimepicker here: [http://xdsoft.net/jqplugins/datetimepicker/](http://xdsoft.net/jqplugins/datetimepicker/) then you'll find it uses PHP format specifiers. If you want Django and the datetimepicker to populate a field in the same way, you need to ensure they use the same format. So I add to the Django from context the default format as follows: `context["default_datetime_input_format"] = datetime_format_python_to_PHP(DATETIME_INPUT_FORMATS[0])` and in the template Javascript on my form for the datetimepicker i give it: `"format": {{default_datetime_input_format}}` and the datetimepicker now populates the the datetime field in the same format as Django.
The filter is **specific to datetime objects** and no allowance has been made to convert strings or epoch times. Also **no type checking** is performed so misuse will result in an error. To use include the above snippet in a file called templatetags/customfilters.py or append to existing filters file then load: `{% load customfilters %}` in your template, then to use it: `{{ dateobject|adjust:"months=1"|date:"Y/m/d" }}` To push the dateobject forward by a month, or: `{{ dateobject|adjust:"weeks=-1"|date:"Y/m/d" }}` To push the dateobject back a week, or: `{{ dateobject|adjust:"years=1, months=2"|date:"Y/m/d" }}` To push the dateobject forward by a year and 2 months
should probably be migrated to an inclusion tag to allow a source timezone that isn't the site specific TIME_ZONE. This code assumes that your database stores dates according to the django.conf.settings.TIME_ZONE variable. Yes.. this assumes that dates are stored in the database according to system time. On my systems the system time of a server is always UTC therefore avoiding problems with datetime (no tz info) columns in backend databases having no timezone information and stored according to the database or system timezone information. I find it a good practice to always use UTC for any stored information and always retrieve information as UTC and localize the date during display.
This snippet display a human readable date diff. You give it the your date in parameter and the diff with datetime.datetime.now() is returned. The diff must be positive to be more accurate (future dates are not supported) Usage: {{ status.created_at|date_diff }} Will give something like: less than 1 minute ago 13 minutes ago 1 hour ago etc. Based on [Fuzzy Date Diff Template Filter](http://www.djangosnippets.org/snippets/1347/)
I have a model with a datetime field that I used as a timestamp. I’m in California’s timezone (“America/Los_Angeles”). The data is saved in UTC in MySQL (as confirmed by the ORM). I just want to do a query that looks like this: “give me all the information with day X’s timestamp” (24 hour period). But the timestamp is a datetime, not date. If you just do varname.date(), it’s still UTC’s date, not your local timezone’s date. Here’s what I did: 1. First construct the start and end time period covering the 24 hour period of that day you want 2. Make it an “aware” (not naive) datetime 3. Filter for the __range
A DateTime field extension that automatically stores the timezone, and the computed UTC equivalent. This field needs the pytz library. The field adds two new fields to the model, with the same name of the UTCDateTimeField field, and a suffix. For an UTCDateTimeField named 'updated', the model will contain * an 'updated' field, which holds the local datetime * an 'updated_utc' field, which holds the corresponding UTC datetime * an 'updated_tz' field, which holds the field timezone name The timezone can vary between model instances, just set the 'xxx_tz' field to the desired timezone before saving. UTCDateTimeField supports a single optional keyword argument 'default_tz', in addition to the DateTimeField standard ones, to let the user choose a provider for a default timezone when no timezone has been set. Its value can be * None (or the argument missing), in which case the default settings.TIME_ZONE will be used * a callable, which will be called when the 'xxx_tz' field is emtpy, which should return a timezone name * a string, which will be used to access a model attribute or call a model method, which should return a timezone name If the timezone name points to a non-existent timezone, a warning will be issued and the default settings.TIME_ZONE value will be used. The field will also add three properties to the model, to access the pytz timezone instance, and the offset aware datetimes for local time and UTC. For the same 'updated' field instance we used above, the three properties added to the model will be: * updated_timezone * updated_offset_aware * updated_utc_offset_aware A brief example on how to use UTCDateTimeField: class UTCDateTimeTest(models.Model): """ >>> import datetime >>> d = datetime.datetime(2007, 8, 24, 16, 46, 34, 762627) # new instance, tz from model method >>> t = UTCDateTimeTest(updated=d) >>> t.save() >>> t.updated datetime.datetime(2007, 8, 24, 16, 46, 34, 762627) >>> t.updated_utc datetime.datetime(2007, 8, 24, 14, 46, 34, 762627) >>> t.updated_tz 'Europe/Rome' >>> t.updated_timezone <DstTzInfo 'Europe/Rome' CET+1:00:00 STD> >>> t.updated_offset_aware datetime.datetime(2007, 8, 24, 16, 46, 34, 762627, tzinfo=<DstTzInfo 'Europe/Rome' CEST+2:00:00 DST>) >>> t.updated_utc_offset_aware datetime.datetime(2007, 8, 24, 14, 46, 34, 762627, tzinfo=<UTC>) >>> """ updated = UTCDateTimeField(default_tz='get_tz') def get_tz(self): return 'Europe/Rome'
This subclass of django.models.Field stores a python datetime.timedelta object as an integer column in the database. It includes a TimedeltaFormField for editing it through djangos admin interface. Feedback welcome. 2011-04-20: TimedeltaField can now be (de)serialized. Tested with JSON. 2009-11-23: `_has_changed()` added. Before form.changed_data contained timedelta FormFields, even if nothing changed.
This wil format the date to today at 1:03 pm , yesterday at 9:13 pm, 22 August at 10:08 pm
This widget uses: [DHTML Calendar Widget](http://www.dynarch.com/projects/calendar/). It is very simple implementation but may be easily extended/changed/refined. 1. Necessary files: First download calendar package and extract it to your MEDIA folder (MEDIA/calendar/...) You'll also need a small gif that will be shown as a button that allows user to display calendar. By default this 'gif' is searched at '[MEDIA]images/calbutton.gif' but you may change this path in the code (calbtn variable). You need to download or create callbutton.gif image by yourself (it is not included). 2. Include css and js files in your page (as shown in the comment in the code). 3. In form code assign a widget to a field as usual (see newforms documentation for more details). 4. It is possible to change date format by specifying different value for 'dformat' attribute of widget class. If you get javascript errors while trying to open calendar try to use english translation file (calendar-en.js). I've found that some translations, eg. Polish, are broken by default. In this case you should override your language translation with english one and translate it by yourself (it is easy).
Form fields use the dateutil module [http://labix.org/python-dateutil](http://labix.org/python-dateutil) to parse natural-language input for date and datetime fields. The callback function will replace all date and datetime fields automatically for form_for_model and form_for_instance. **Note**: by replacing the 'form_class' keyword argument instead of just returning the field itself you preserve the 'required' status of the field.
Takes the current DateTime and adds either days, hours, minutes, or seconds to the datetime object.
Variation on SplitDateTimeField that does not enforce the Time to be required, accepting a default instead.
Though this may not be Django (just basic Python) this kind of thing sure does come in handy! __Plus, it's super easy to edit for any datetime format you want to throw at it.__