|
Will this issue be assigned to a developer and solved some days???
How many developers are working on firebird? In a global used application UTC is a MUST HAVE!! Without UTC support, firebird will loose acceptance. I disagree with Christian Pradelli,
and I agree to Ann Harrison. At most it is a decision of an application what kind of date/time has to be used or presented. So, use of data types like timestamp with/without timezone (where classical datetime = datetime without timezone) and clauses like "current_datetime at timezone xxx" seems to be the right way - from my pont of view. Backward compatibility: datetime = datetime without timezone current_datetime = current_datetime at local timezone Extensions: UTC shall be a valid timezone Christian, how do you suggest to provide backward compatibility in this case?
I think that the correct behavior should be:
Firebird should automatically store all date/times in UTC and each client connection should specify it own timezone. dates/times should be converted/displayed using the client timezone Timezone should be taken from client OS setting and could be changed in a global user variable. That's true. Is there a timeline to solve this issue?
This issue seems to be the same as CORE-909.
MySQL (I know) has the following:
UNIX_TIMESTAMP() Return a UNIX timestamp UTC_DATE()(v4.1.1) Return the current UTC date UTC_TIME()(v4.1.1) Return the current UTC time UTC_TIMESTAMP()(v4.1.1) Return the current UTC date and time http://dev.mysql.com/doc/refman/5.1/en/date-and-time-functions.html All of the above are *very* useful, and none is in SQL-99 as far as I know. All of the above return temporal data independent of any timezone configured on the server machine, and therefore independent of any random changes (like DST) configured in the timezone (zoneinfo on Linux, or Olson database). These functions allow the application developer to isolate his application from any OS timezone settings and changes. I've found purely arithmetic timezone functionality (as defined in another standard) to be of limited usefulness: [xsl] Timezone concept broken in XPath 2.0? http://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/200811/msg00088.html Wrong approach. Instead add the standard SQL types of TIMESTAMP WITH TIMEZONE and TIME WITH TIME ZONE. Messing with existing data types just leads to unhappiness.
For client parsed dates this would not even require any code change: Just specify explicitly that the time information on the wire is suppost to be interpreted as UTC.
For conversion from/to text, the timezone should be recognized (defaulting to the clients timezone) and antomatically converted to UTC. |
||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Support timezones with timestamp
We normally store TIMESTAMP in UTC in databases. So UTC_NOW would already help to calculate the age of events.
It is very unhandy to still use an UDF to get time and date in UTC or lets do the application do all conversions.
And without an UDF, some selections and calculation of TIMESTAMP in UTC are not possible in stored procedures.
Remark:
On the way to implement access to current time in UTC as UDF I found the undocumented function getExactTimestampUTC() in fb_udf, implemented at least for Windows platforms. So I can go on ....