Hi ya'll, Here is my first patch submission of this series. Hope you like it. Problems solved: * Date field data is now returned to the integer state before code reaches the submit stage (changed actually by the validation stage). The change is transparent to modules expecting the integer value to be in $edit. * Dates were creeping backwards by a day each time a form was submitted. This is now fixed. Problem was with expand_date() using the timestamps if user timestamps are enabled. Problem was only evident when using positive timezone offsets. See discussion at the end of this mail for more details. * Date field data is now automatically validated for correctness as a date. I.e whether the silly user entered in 31/Feb/2001. An error message is added with form_set_error(). * Select fields didn't flag errors found in their data. I.e the class attribute of select fields was not set by theme_select. * Date fields didn't display errors as the error cases didn't cascade into the child elements in the form array structures. Lemme know if there is something wrong with this stuff. Discussion ---------- IMO date fields can be classified into two different requirements. First is the kind of date which is the same regardless of your timezone. An example of this is a birthday. Second, the kind of date that changes depending on location such as the submission time of a comment. Dates must to be placed into one of these categories before timezone support is feasible. The first category, dates without timezone, can be displayed by the current date implementation. Unfortunately, the second cannot and must be linked with the time part of the timestamp _at_all_times_. For this reason I proposed a time and datetime time to be placed in core. I'm going to implement the two types and submit a patch. The datetime field will support timezones and the time field will not for the reasons above. As for timezone support overall... there are two snags i ran into while doing some testing. 1) format_date() will break on Windows because it uses gmdate/date. 2) format_date() is broken anyway in the way it calculates the new timestamp. I.e the timestamp must be converted to UTC before adding the timezone to it. Here is an example: say system timezone is +1100 (UNIX timestamp) and user timezone is -0300 timestamp = 2006-02-01 00:00:00 timestamp += timezone // == 2006-01-31 21:00 **wrong** timestamp = 2006-02-01 00:00:00 timestamp -= system_timezone // == 2006-01-31 13:00 timestamp += timezone // == 2006-01-31 10:00 **right!** I haven't fixed this yet as I need more information from developers and decision makers involved with drupal. I have the solution to this in my head. The decision to be made is whether the database stores localtime or UTC. localtime is better because it makes it possible to query the database without doing conversions from UTC. UTC is better because it avoids the common time hurdle with drupal - timezone support sucks. Many of the developers on this list have responded to me with workarounds for various things. Thank you for those. Additionally, i've received something like, "we don't have enough time to put this stuff into drupal before releasing 4.7". The efforts you've all put in has been astounding and by far 4.7 is a major leap forward for drupal. Unfortunately, the celebration of 4.7 is marred for me, and no doubt many others, because fundamental things like date support are still broken since the days of 4.4. How can you even suggest releasing a product out to market that fails to meet the minimum standard of operability and call it a release? Would an OS be released if dates were broken? Even MS won't do that anymore! Drupal is like an OS and the applications are the modules. Don't forget that! <take in a deep breath> All better now. I'm off to add these types to the system. Happy patching! -- Sammy Spets Synerger Pty Ltd http://www.synerger.com/