time
LA Drupal Jan '09 Meeting Poll: Did you enjoy seeing Drush in action?
What time would work best for the Tuesday November 18th meeting in American Fork for everyone?
Specified signup times
My appologises if this has already been discussed but I was wondering if there is a patch (or otherwise) which allows the signup schedule module to more exactly specify the opening and closing time than just midnight on the said day. And if there isn't I was hoping someone would be willing to create said patch as I think it would be very useful for event signups to give more control over the signup period.
Keeping track of time spent on an issue
for my issue tracking needs at my day job (http://www.cs.wisc.edu/condor), we'd like to start keeping track of how long we spend on a given issue. mostly, we'd use this for our internal development tasks, not so much the "helpdesk" style end-user support (though i could see us caring about time spent in those issues, too).
clearly, this is something a lot of issue tracking systems already support, and lots of people need this kind of functionality (though often in more corporate environments). however, i'm not sure we'd want anything like this in the issue queues for drupal.org (though i'm not really sure... i could potentially see it being useful, even there, though for different reasons). generally, i'm leaning away from wanting to have any of this functionality on drupal.org.
Time to move away from timestamp?
In my opinion, the use of timestamps for the representation of dates in Drupal core is problematic. It is fine for recording all events that happen now, and it is even fine for recording historical events, as long as they happened 1970 or later. They are utterly useless if you want to make a geneology site.
More disturbingly, the event module also relies on timestamps for representation of events. As far as I can tell, this is a huge limitation. The CCK date field uses the ISO 8601 standard which saves times as as string: 20060610T20:47:48+01:00. While there are lots of arguments about how the data should be persisted in the database, to me, it is clear that the ISO 8601 string is ideal for representing the date in Drupal code (unless you're doing archeology, then I've got no idea what you do with BC dates).



