no date / time types in schema API
Hi, http://en.wikibooks.org/wiki/SQL_dialects_reference/Data_structure_definitio... All (but one) SQL dialects have a date type. However, Drupal's Schema API does not seem to have a type for date only: http://drupal.org/node/159605 It causes schema.module to complain: no type for Schema type date:normal. I am concerned that with the new Schema API, my modules may not install properly anymore. (how can it install a table where a column has an unsupported type?) Is this a purposeful omission? I just found this issue: http://drupal.org/node/200953 so others noticed, too :) How are you all coping with the lack of time/date data type? What workarounds do you use? I could use the data type datetime, but then I have to worry about truncating the time part which I do not need. I use substr() to truncate the part I don't want, but coder.module complains about it (says I should use drupal_substr() while substr() is quicker and safe in this case). There is probably a better way to truncate the time part (please say), but it feels a shame to have to deal with the extraneous time part when Schema API could easily handle date types. Blessings, Augustin.
On Wed, Jul 2, 2008 at 12:18 PM, augustin (beginner) < drupal.beginner@wechange.org> wrote:
Hi,
http://en.wikibooks.org/wiki/SQL_dialects_reference/Data_structure_definitio... All (but one) SQL dialects have a date type. However, Drupal's Schema API does not seem to have a type for date only: http://drupal.org/node/159605
As I said in #252916 [1], I think DATE / TIME and DATETIME types are really things of the past. I understand how they could have been useful in the 80s and 90s, especially on text-based terminals (they are fixed-length!), but nowadays they are more a nuisance than anything. Database engines have their own implementation specificities: for example, the Oracle implementation expects the order of arguments to be locale dependant! A solution based on timestamps is much more elegant: timestamps need no (database-specific) parsing whatsoever (both on reading and writing to the database), they play nice with arithmetic (and thus do not need any helper functions), and are consistent with the implementation of most application, including Drupal. So let's drop the support for them completely in the Schema API. Core don't use them, please don't encourage contribution modules to. Damien Tournoud [1] http://drupal.org/node/252916
On Wednesday 02 July 2008 18:36:15 Damien wrote:
A solution based on timestamps is much more elegant: timestamps need no (database-specific) parsing whatsoever (both on reading and writing to the database), they play nice with arithmetic (and thus do not need any helper functions), and are consistent with the implementation of most application, including Drupal.
How do you use a timestamp when you need the date 18 Aug 1908 on a date field??? Augustin.
Maybe what you want is strtotime? http://www.php.net/manual/en/function.strtotime.php On Wed, Jul 2, 2008 at 1:59 PM, augustin (beginner) < drupal.beginner@wechange.org> wrote:
On Wednesday 02 July 2008 18:36:15 Damien wrote:
A solution based on timestamps is much more elegant: timestamps need no (database-specific) parsing whatsoever (both on reading and writing to the database), they play nice with arithmetic (and thus do not need any helper functions), and are consistent with the implementation of most application, including Drupal.
How do you use a timestamp when you need the date 18 Aug 1908 on a date field???
Augustin.
-- Ashraf Amayreh http://blogs.aamayreh.org
On Wednesday 02 July 2008 19:04:46 Ashraf Amayreh wrote:
Maybe what you want is strtotime?
Errr, no, it doesn't work. Read again the date I provided. But thanks. I didn't know this function and it might prove useful one day. Thanks to Gerhard for his reply. I just upgraded a big module to schema API, but I will have to revert about half back and use db_query() instead, as he recommends. I have absolutely no clue how the database layer, the next generation (http://drupal.org/node/225450 ) will affect this issue. Meanwhile, a database is supposed to store data. It's a bug to limit the kind of data that a database can store, and use php to manipulate that data every which way. To say that nobody needs it is a bit presumptuous. The role of Drupal core is to empower module maintainer to use their creativity to code module for every possible need. You cannot use a timestamp to store dates before or after the UNIX period. You cannot use datetime to store a duration, or the time of a recurring meeting. The 'date' or the 'time' data type are perfectly suited for certain special applications but this bug forces us to dance around the imposed limitation and use php to manipulate the data when the proper data could be directly stored instead. In short, I do agree it's a bug. Augustin.
On Wed, 2 Jul 2008 19:19:56 +0800, "augustin (beginner)" <drupal.beginner@wechange.org> wrote:
On Wednesday 02 July 2008 19:04:46 Ashraf Amayreh wrote:
Maybe what you want is strtotime?
Errr, no, it doesn't work. Read again the date I provided. But thanks. I didn't know this function and it might prove useful one day.
Thanks to Gerhard for his reply. I just upgraded a big module to schema API, but I will have to revert about half back and use db_query() instead, as he recommends.
I have absolutely no clue how the database layer, the next generation (http://drupal.org/node/225450 ) will affect this issue.
In the short term, it won't. That patch does not do anything to Schema API at this point beyond move it into a class structure on the back-end for consistency. There are a lot of things that could and should happen to Schema API that are not going to until that patch lands because it's big enough already. :-) Right now the only remaining issues are chasing HEAD (every time the testing framework has an upgrade it breaks half my tests and I have to go in and refactor them) and Postgres recently starting to segfault on install. I simply don't have the Postgres knowledge to know how to fix that. If you do, *please* contact me. There's a dozen or more tasks that are blocked on us getting Postgres to work completely in the new codebase, and even with the code freeze pushed back time is short. If your skill set includes Postgres and PDO, you have just found your calling. :-) Early on I toyed with the idea of doing driver-specific field overrides. The concept was that you could pass, say, a PHP DateTime object in as a "value" and it would get formatted down to the proper format expected for a given database. That wouldn't help on read, though. I've tabled that for the time being as it requires a lot more thought and I refuse to put more thought into it until the current patch lands. Timestamps suck. "Native" date/time fields suck. Time/date handling in general just sucks. It's just a question of which form of suckage you want to have to deal with. --Larry Garfield
No, gmmktime() is a better choice. ----- "Ashraf Amayreh" wrote:
Maybe what you want is strtotime?
On Wed, Jul 2, 2008 at 1:59 PM, augustin (beginner) < drupal.beginner@wechange.org > wrote:
On Wednesday 02 July 2008 18:36:15 Damien wrote:
A solution based on timestamps is much more elegant: timestamps need no (database-specific) parsing whatsoever (both on reading and writing to the database), they play nice with arithmetic (and thus do not need any helper functions), and are consistent with the implementation of most application, including Drupal.
How do you use a timestamp when you need the date 18 Aug 1908 on a date field???
Augustin.
-- Ashraf Amayreh http://blogs.aamayreh.org
augustin (beginner) wrote:
On Wednesday 02 July 2008 18:36:15 Damien wrote:
A solution based on timestamps is much more elegant: timestamps need no (database-specific) parsing whatsoever (both on reading and writing to the database), they play nice with arithmetic (and thus do not need any helper functions), and are consistent with the implementation of most application, including Drupal.
How do you use a timestamp when you need the date 18 Aug 1908 on a date field???
Augustin.
Just to clarify, there is a significant difference between most DB implementations of a timestamp [1,2] and a unix timestamp [3]. 1. http://dev.mysql.com/doc/refman/5.0/en/timestamp.html 2. http://www.postgresql.org/docs/8.3/static/datatype-datetime.html 3. http://us3.php.net/manual/en/function.time.php -- Jonathan Hedstrom OpenSourcery http://opensourcery.com Technology for Good
----- "augustin (beginner)" <drupal.beginner@wechange.org> wrote:
On Wednesday 02 July 2008 18:36:15 Damien wrote:
A solution based on timestamps is much more elegant: timestamps need no (database-specific) parsing whatsoever (both on reading and writing to the database), they play nice with arithmetic (and thus do not need any helper functions), and are consistent with the implementation of most application, including Drupal.
How do you use a timestamp when you need the date 18 Aug 1908 on a date field???
You use the UNIX timestamp at 00:00 UTC that day.
David, Read up on "Unix Epoch". The unix timestamp 0 corresponds to January 1, 1970. So it's rather difficult to represent a date before that year. Also, implementations do or do not take timezones into account wich makes it even more difficult. Regards, Olivier David Timothy Strauss wrote:
----- "augustin (beginner)" <drupal.beginner@wechange.org> wrote:
On Wednesday 02 July 2008 18:36:15 Damien wrote:
A solution based on timestamps is much more elegant: timestamps need no (database-specific) parsing whatsoever (both on reading and writing to the database), they play nice with arithmetic (and thus do not need any helper functions), and are consistent with the implementation of most application, including Drupal. How do you use a timestamp when you need the date 18 Aug 1908 on a date field???
You use the UNIX timestamp at 00:00 UTC that day.
You forget: * Negative numbers * That we've even discussed such negative numbers in this thread -----Original Message----- From: Olivier Jacquet <ojacquet@jax.be> Date: Fri, 04 Jul 2008 21:30:30 To: <development@drupal.org> Subject: Re: [development] no date / time types in schema API David, Read up on "Unix Epoch". The unix timestamp 0 corresponds to January 1, 1970. So it's rather difficult to represent a date before that year. Also, implementations do or do not take timezones into account wich makes it even more difficult. Regards, Olivier David Timothy Strauss wrote:
----- "augustin (beginner)" <drupal.beginner@wechange.org> wrote:
On Wednesday 02 July 2008 18:36:15 Damien wrote:
A solution based on timestamps is much more elegant: timestamps need no (database-specific) parsing whatsoever (both on reading and writing to the database), they play nice with arithmetic (and thus do not need any helper functions), and are consistent with the implementation of most application, including Drupal. How do you use a timestamp when you need the date 18 Aug 1908 on a date field???
You use the UNIX timestamp at 00:00 UTC that day.
And no, the UNIX epoch is always relative to Jan 1, 1970 00:00 UTC. -----Original Message----- From: Olivier Jacquet <ojacquet@jax.be> Date: Fri, 04 Jul 2008 21:30:30 To: <development@drupal.org> Subject: Re: [development] no date / time types in schema API David, Read up on "Unix Epoch". The unix timestamp 0 corresponds to January 1, 1970. So it's rather difficult to represent a date before that year. Also, implementations do or do not take timezones into account wich makes it even more difficult. Regards, Olivier David Timothy Strauss wrote:
----- "augustin (beginner)" <drupal.beginner@wechange.org> wrote:
On Wednesday 02 July 2008 18:36:15 Damien wrote:
A solution based on timestamps is much more elegant: timestamps need no (database-specific) parsing whatsoever (both on reading and writing to the database), they play nice with arithmetic (and thus do not need any helper functions), and are consistent with the implementation of most application, including Drupal. How do you use a timestamp when you need the date 18 Aug 1908 on a date field???
You use the UNIX timestamp at 00:00 UTC that day.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Damien schrieb:
On Wed, Jul 2, 2008 at 12:18 PM, augustin (beginner) < drupal.beginner@wechange.org> wrote:
Hi,
http://en.wikibooks.org/wiki/SQL_dialects_reference/Data_structure_definitio... All (but one) SQL dialects have a date type. However, Drupal's Schema API does not seem to have a type for date only: http://drupal.org/node/159605
As I said in #252916 [1], I think DATE / TIME and DATETIME types are really things of the past. I understand how they could have been useful in the 80s and 90s, especially on text-based terminals (they are fixed-length!), but nowadays they are more a nuisance than anything. Database engines have their own implementation specificities: for example, the Oracle implementation expects the order of arguments to be locale dependant!
A solution based on timestamps is much more elegant: timestamps need no (database-specific) parsing whatsoever (both on reading and writing to the database), they play nice with arithmetic (and thus
You obviously have never dealt with timestamps for dates... They are a most royal PITA, especially when dealing with timezones and DST. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIa2Ncfg6TFvELooQRAvauAJ9Wgb09MJsXkeatskNmhVw3996yNgCgp1Ws 635A/W2d3MssqbWMyfxRiEA= =jxJz -----END PGP SIGNATURE-----
On Wed, 2 Jul 2008 12:36:15 +0200 Damien <damz@prealable.org> wrote:
On Wed, Jul 2, 2008 at 12:18 PM, augustin (beginner) < drupal.beginner@wechange.org> wrote:
http://en.wikibooks.org/wiki/SQL_dialects_reference/Data_structure_definitio... All (but one) SQL dialects have a date type. However, Drupal's Schema API does not seem to have a type for date only: http://drupal.org/node/159605
As I said in #252916 [1], I think DATE / TIME and DATETIME types are really things of the past. I understand how they could have been useful in the 80s and 90s, especially on text-based terminals (they are fixed-length!), but nowadays they are more a nuisance than anything. Database engines have their own implementation
Most decent DB let you modify the default format or pass specific parameters to adjust the input/output format and php handles formats pretty well too. If altering the default date format is not an option, it shouldn't be since none of the DB I know force you to set it on an instance basis, conversion can be made at substitution time in db_query or inside a new wrapper that will support prepared statements. PHP 5 has a DateTime object that seems to support timezones pretty well.
specificities: for example, the Oracle implementation expects the order of arguments to be locale dependant!
locale is a pretty complicated subject. It would be nice if it was thread-safe in php: http://it.php.net/setlocale The locale information is maintained per process, not per thread. If you are running PHP on a multithreaded server api like IIS or Apache on Windows you may experience sudden changes of locale settings while a script is running although the script itself never called setlocale() itself. This happens due to other scripts running in different threads of the same process at the same time changing the processwide locale using setlocale(). Having a thread-safe locale would solve a lot of problems for i18n since implementing a reasonably complete and flexible data localisation is complicated and resource hungry in php. But that doesn't look as an Oracle DB problem since you can alter the default date/time format at many levels (DB instance, connection, statement). PostgreSQL can do the same with "set datestyle" or DB wide with postmaster -e. I forgot how to achieve this with MS SQL, but it can be done. I bet someone more versed than me with MySQL know the cetacean equivalent.
A solution based on timestamps is much more elegant: timestamps need no (database-specific) parsing whatsoever (both on reading and writing to the database), they play nice with arithmetic (and thus do not need any helper functions), and are consistent with the implementation of most application, including Drupal.
timestamps don't have even a rough idea about what a calendar or a timezone are. Most reasonable DB have it and this knowledge can be exploited to large extents without the need to re-implement it in php or force php to work as if it was sql and/or moving unnecessarily data around. eg. filter all events happening on Sunday between 11:00am and 1:00pm GMT or local time. Considering timestamps and dates interchangeable is risky at least. augustin, I hope this can help even if it just move the problem elsewhere: most DB also support a form of extract (that "surprisingly" is part of SQL standard). http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html http://www.postgresql.org/docs/8.1/static/functions-datetime.html -- Ivan Sergio Borgonovo http://www.webthatworks.it
A timezone should not be stored within the same field as a time. It should be stored separately and used to calculate local times, as necessary. The entire idea of storing a timestamp as a local time alongside its timezone is bad on so many levels. Oh, and good luck dealing with your DB server sometimes having a different timezone than your web server. -----Original Message----- From: Ivan Sergio Borgonovo <mail@webthatworks.it> Date: Wed, 2 Jul 2008 14:52:28 To: <development@drupal.org> Subject: Re: [development] no date / time types in schema API On Wed, 2 Jul 2008 12:36:15 +0200 Damien <damz@prealable.org> wrote:
On Wed, Jul 2, 2008 at 12:18 PM, augustin (beginner) < drupal.beginner@wechange.org> wrote:
http://en.wikibooks.org/wiki/SQL_dialects_reference/Data_structure_definitio... All (but one) SQL dialects have a date type. However, Drupal's Schema API does not seem to have a type for date only: http://drupal.org/node/159605
As I said in #252916 [1], I think DATE / TIME and DATETIME types are really things of the past. I understand how they could have been useful in the 80s and 90s, especially on text-based terminals (they are fixed-length!), but nowadays they are more a nuisance than anything. Database engines have their own implementation
Most decent DB let you modify the default format or pass specific parameters to adjust the input/output format and php handles formats pretty well too. If altering the default date format is not an option, it shouldn't be since none of the DB I know force you to set it on an instance basis, conversion can be made at substitution time in db_query or inside a new wrapper that will support prepared statements. PHP 5 has a DateTime object that seems to support timezones pretty well.
specificities: for example, the Oracle implementation expects the order of arguments to be locale dependant!
locale is a pretty complicated subject. It would be nice if it was thread-safe in php: http://it.php.net/setlocale The locale information is maintained per process, not per thread. If you are running PHP on a multithreaded server api like IIS or Apache on Windows you may experience sudden changes of locale settings while a script is running although the script itself never called setlocale() itself. This happens due to other scripts running in different threads of the same process at the same time changing the processwide locale using setlocale(). Having a thread-safe locale would solve a lot of problems for i18n since implementing a reasonably complete and flexible data localisation is complicated and resource hungry in php. But that doesn't look as an Oracle DB problem since you can alter the default date/time format at many levels (DB instance, connection, statement). PostgreSQL can do the same with "set datestyle" or DB wide with postmaster -e. I forgot how to achieve this with MS SQL, but it can be done. I bet someone more versed than me with MySQL know the cetacean equivalent.
A solution based on timestamps is much more elegant: timestamps need no (database-specific) parsing whatsoever (both on reading and writing to the database), they play nice with arithmetic (and thus do not need any helper functions), and are consistent with the implementation of most application, including Drupal.
timestamps don't have even a rough idea about what a calendar or a timezone are. Most reasonable DB have it and this knowledge can be exploited to large extents without the need to re-implement it in php or force php to work as if it was sql and/or moving unnecessarily data around. eg. filter all events happening on Sunday between 11:00am and 1:00pm GMT or local time. Considering timestamps and dates interchangeable is risky at least. augustin, I hope this can help even if it just move the problem elsewhere: most DB also support a form of extract (that "surprisingly" is part of SQL standard). http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html http://www.postgresql.org/docs/8.1/static/functions-datetime.html -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Wed, 2 Jul 2008 14:07:27 +0000 "David Strauss" <david@fourkitchens.com> wrote:
A timezone should not be stored within the same field as a time. It should be stored separately and used to calculate local times, as necessary.
The entire idea of storing a timestamp as a local time alongside its timezone is bad on so many levels.
You're not forced to store dates with tz but having a data type that understand tz and support tz operations inside the DB is pretty helpful. Again... suppose you store datetime in GMT and you want to know who had a beer before 1:00am local time maybe during a DTS change [evil grin]? a tz is not an integer. You can't compute the interval on the PHP side and you don't want to return all the times and filter on the PHP side either. Anyway tz support across different DB looks much harder to handle than different date format since the "interface" is much more heterogeneous.
Oh, and good luck dealing with your DB server sometimes having a different timezone than your web server.
That's life. Anyway MySQL as well as PostgreSQL provide nifty settings to cope with the problem. -- Ivan Sergio Borgonovo http://www.webthatworks.it
----- "Ivan Sergio Borgonovo" <mail@webthatworks.it> wrote:
You're not forced to store dates with tz but having a data type that understand tz and support tz operations inside the DB is pretty helpful.
Again... suppose you store datetime in GMT and you want to know who had a beer before 1:00am local time maybe during a DTS change [evil grin]? a tz is not an integer. You can't compute the interval on the PHP side and you don't want to return all the times and filter on the PHP side either.
I have never written an application that needed to answer a time question based on the local time for all rows. Your proposal of using date/time columns in the database doesn't fix it, either. You can't query based on "local time" even if MySQL knows all the timezone data.
Anyway tz support across different DB looks much harder to handle than different date format since the "interface" is much more heterogeneous.
That is also a problem.
Oh, and good luck dealing with your DB server sometimes having a different timezone than your web server.
That's life. Anyway MySQL as well as PostgreSQL provide nifty settings to cope with the problem.
Why cope when you can avoid the problem entirely?
On Wed, 2 Jul 2008 10:21:29 -0500 (CDT) David Timothy Strauss <david@fourkitchens.com> wrote:
----- "Ivan Sergio Borgonovo" <mail@webthatworks.it> wrote:
You're not forced to store dates with tz but having a data type that understand tz and support tz operations inside the DB is pretty helpful.
Again... suppose you store datetime in GMT and you want to know who had a beer before 1:00am local time maybe during a DTS change [evil grin]? a tz is not an integer. You can't compute the interval on the PHP side and you don't want to return all the times and filter on the PHP side either.
I have never written an application that needed to answer a time question based on the local time for all rows.
Lucky you.
Your proposal of using date/time columns in the database doesn't fix it, either. You can't query based on "local time" even if MySQL knows all the timezone data.
You can at least in postgresql if you use the right functions and define a suitable schema. I think it would even be easier on MySQL that store tz data in tables... or well maybe I don't know well enough internals of pg in this area, but I know it would be possible without moving around data. I didn't say it is common or trivial but missing the functions that support tz in the DB is going to make the task much harder once you've to answer a time question based on local time. If you want to organise a meeting and you want to collect stats about what are the most busy hours among your managers you've to deal with GMT as well as local times. Storing data in a proper data type will make dealing with tz inside the DB efficient even if not directly from the Drupal DB API. tz aren't integers either so properly dealing with tz is not going to be easy... I think every solution to the tz problem in Drupal is going to be a hack for the near future, timestamps aren't going to help providing a solid solution.
Oh, and good luck dealing with your DB server sometimes having a different timezone than your web server.
That's life. Anyway MySQL as well as PostgreSQL provide nifty settings to cope with the problem.
Why cope when you can avoid the problem entirely?
Because sometimes you've to cope and you can't avoid the problem. Having support for tz in the DB doesn't seem bad... but it is an area of larger jeopardization than datetime support across DB and it looks as it is going to be solved later than just datetime support in D7. Anyway having support for proper dates in the DB opens the possibility of much more complex queries that otherwise would require a lot of data moving around. Simple things like returning all the submitted posts on Sunday aren't possible other than moving a lot of data around if you store dates in timestamps... oh yes you can... once you build up a query that convert the timestamp to a native data type and... but well that's not going to make your query faster and still you'll have to deal with conversion somewhere... So better that DB know the nature of the data it is storing: it helps building up where clauses and it helps maintaining consistency and quality of stored data. Otherwise we would be storing everything in a BLOB or use the filesystem and grep. -- Ivan Sergio Borgonovo http://www.webthatworks.it
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 augustin (beginner) schrieb:
http://en.wikibooks.org/wiki/SQL_dialects_reference/Data_structure_definitio... All (but one) SQL dialects have a date type.
However, Drupal's Schema API does not seem to have a type for date only: http://drupal.org/node/159605
It causes schema.module to complain: no type for Schema type date:normal. I am concerned that with the new Schema API, my modules may not install properly anymore. (how can it install a table where a column has an unsupported type?)
Just do a normal db_query. I've had to do that for event.module since it needs a time type.
Is this a purposeful omission?
IIRC it was decided that "nobody needs it" or "it is too complicated because of pgsql". IMO it's a bug.
How are you all coping with the lack of time/date data type? What workarounds do you use?
See event.install. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIa1zUfg6TFvELooQRAhiGAKDD+LFNzxsHswjASEioEMahb6NElgCfX8yM qaPIvws5zCsr64hPl7sz/tE= =vmeQ -----END PGP SIGNATURE-----
"augustin (beginner)" <drupal.beginner@wechange.org> writes:
All (but one) SQL dialects have a date type. However, Drupal's Schema API does not seem to have a type for date only: http://drupal.org/node/159605
Is this a purposeful omission? What workarounds do you use?
It is not so much a purposeful omission as a problem I did not put effort into solving because, when I asked, no one told me it mattered. To have a Schema API type for dates and times require that it be able to map meaningfully to a native db type on all dbs we want to support. I thought that date and time types would be inconsistent between various dbs. I did put in one type, datetime, that works on mysql and pgsql, but did not try to find portable types for time and date separately. That said, there is a workaround: You can declare db-specific column types in the Schema API field structure, using mysql_type and pgsql_type, like this: $schema['mytable'] = array( 'fields' => array( 'mycolumn' => array('mysql_type' => 'date', 'pgsql_type' => 'whatever', ....)));
There is probably a better way to truncate the time part (please say), but it feels a shame to have to deal with the extraneous time part when Schema API could easily handle date types.
If you have a specific suggestion for what the Schema API date and time related types should be and how they should map to mysql and pgsql native types, by all means submit an issue at d.o. Thanks, Barry
participants (11)
-
Ashraf Amayreh -
augustin (beginner) -
Barry Jaspan -
Damien -
David Strauss -
David Timothy Strauss
-
Gerhard Killesreiter -
Ivan Sergio Borgonovo -
Jonathan Hedstrom -
Larry Garfield -
Olivier Jacquet