TIME-ZONE date format..

Hi, I need to store/display the 'time-zone' along with date-time information into a date column. Does anyone know what date-format i can use for the time-zone.
Thank you very much for your help,
sanjana.

Hi Utpal,
Thanks a lot! However, we are using Oracle version 8i at our project..i dont think 8i has these new datatypes. Do let me know if you think of anything else for v.8i
Thanks very much,
Sanjana.
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by UTPAL DHAR ([email protected]):
Hi Sanjana,
I guess Oracle 9i has a few new DATE Datatypes called :
TIMESTAMP Datatype
TIMESTAMP WITH TIME ZONE Datatype and
TIMESTAMP WITH LOCAL TIME ZONE Datatype
You could use these datatypes to store/display the timezone along with the date-time information.
I hope this information is useful to you.
-Utpal Dhar<HR></BLOCKQUOTE>
null

Similar Messages

In the advanced tab of languages and Region the time and date formats will not change

For a certian Application I am using I need to change the format of the Time and Date. I had no problems in Mountain Lion. In the advanced tab of languages and Region the time and date formats will not change. I need the date format to read as 01/01/14 and time format to read 13:00. As I said this was easily done in Mountain Lion and all previous Apple OS. I suspect it's an issue with in the OS.

You're right, it has been that way for a long time. I've never bothered reporting it as a bug since it's simple enough to deal with, but reporting it would be a reasonable thing to do.

Adding time into date format

Hi
Is there any easier way to add time value "now" into a date format with time value 00:00
I managed to add the time
Value(dateVariable)+(Value(Now())-Value(Today()))
I just wander if there is any easiest way to do that or if there is any planed options for that?
Thanks

Hi Brutton
I know about this. My scenario is that I use my custom date picker where user can pick a date. For easier date picking I use date format (today) and then adding day ,month or year into that so the date formant is in time 00:00. I
need to add now time in that date so I can sort entry by date and also by time in a collection I managed to do that with the format mentioned above but I just wander if there is also any other way to do that. We already have excellent code DateAdd where we
can add days months and years but I can't really add time with this code. I don't think that DateAdd can add time into date format or at least I haven't figure it out yet. If not there would be nice to have A TimeAdd code then instead of calculations

Time Zone data downoad failed for 7841 phones

Hi All ,
we have 100 above 7841 phones facing same issue , time changes automatically . when i check the status message it is showing as "time zone data download failed "
CUCM - 8.6.2
Firmware - sip78xx.10-1-1-9

Hi Reddy,
have a look into this discussion
https://supportforums.cisco.com/discussion/12187361/cisco-7821-phones
regds,
aman

Is PGI date beased on system date or user profile time zone date?

Hi All,
When doing PGI what date system will take as Actual good issue date ? whether the System Date or User local Time zone date which maintained in User profile. If you have any idea on this please share.
Regards,
Lakshmikanth

Hi,
You need to check with the basis team for settings this to your local time.
You can also check the field Personal time zone of the user in t.code SU01. I am not sure this will update the timings in the database when the user performs some action.
Regards

Conversion mapping is losing time zone data during daylight saving time

We have a problem with conversion of Calendars to timestamp with timezone for the last hour of Daylight Saving Time (e.g. 01:00 EDT - 01:59 EDT) where it is being interpreted as Standard Time which is in reality 60 minutes later.
We've written a JUnit test case that runs directly against TopLink to avoid any issues with WAS and its connection pooling.
The Calendar theDateTime comes from an object called TimeEntry which is mapped to a TIMESTAMP WITH TIMEZONE field using conversion mapping with Data Type TIMESTAMPTZ (oracle.sql) and Attribute Type Calendar (java.util).
We are using:
Oracle TopLink - 10g Release 3 (10.1.3.0.0) (Build Patch for Bugs 5145690 and 5156075)
Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production
Oracle JDBC driver Version: 10.2.0.1.0
platform=>Oracle9Platform
Execute this Java:
SimpleDateFormat format = new SimpleDateFormat("MM/dd/yyyy HH:mm z");
TimeZone tzEasternRegion = TimeZone.getTimeZone("US/Eastern");
Calendar theDateTime = Calendar.getInstance(tzEasternRegion);
theDateTime.setTime(format.parse("10/29/2006 01:00 EDT"));
Persist to the database and execute this SQL:
SELECT the_date_time, EXTRACT(TIMEZONE_REGION FROM the_date_time), EXTRACT(TIMEZONE_ABBR FROM the_date_time), EXTRACT(TIMEZONE_HOUR FROM the_date_time)
FROM time_table WHERE time_table_id=1
This provides the following results:
THE_DATE_TIME EXTRACT(TIMEZONE_REGION FROM the_date_time) EXTRACT(TIMEZONE_ABBR FROM the_date_time) EXTRACT(TIMEZONE_HOUR FROM the_date_time)
29-OCT-06 01.00.00.000000 AM US/EASTERN US/Eastern EST -5
The wrong time zone is in the database. It should be EDT -4. Let's test the SQL that should be generated by TopLink. It should look like the following.
Execute this SQL:
UPDATE time_table SET the_date_time = TO_TIMESTAMP_TZ('10/29/2006 01:00 US/Eastern','mm/dd/yyyy HH24:MI TZR') WHERE (time_table_id=1)
SELECT the_date_time, EXTRACT(TIMEZONE_REGION FROM the_date_time), EXTRACT(TIMEZONE_ABBR FROM the_date_time), EXTRACT(TIMEZONE_HOUR FROM the_date_time)
FROM time_table WHERE time_table_id=1
This provides the same results:
THE_DATE_TIME EXTRACT(TIMEZONE_REGION FROM the_date_time) EXTRACT(TIMEZONE_ABBR FROM the_date_time) EXTRACT(TIMEZONE_HOUR FROM the_date_time)
29-OCT-06 01.00.00.000000 AM US/EASTERN US/Eastern EST -5
Now, execute this SQL:
UPDATE time_table SET the_date_time = TO_TIMESTAMP_TZ('10/29/2006 01:00 EDT US/Eastern','mm/dd/yyyy HH24:MI TZD TZR') WHERE (time_table_id=1)
SELECT the_date_time, EXTRACT(TIMEZONE_REGION FROM the_date_time), EXTRACT(TIMEZONE_ABBR FROM the_date_time), EXTRACT(TIMEZONE_HOUR FROM the_date_time)
FROM time_table WHERE time_table_id=1
This provides better results:
THE_DATE_TIME EXTRACT(TIMEZONE_REGION FROM the_date_time) EXTRACT(TIMEZONE_ABBR FROM the_date_time) EXTRACT(TIMEZONE_HOUR FROM the_date_time)
29-OCT-06 01.00.00.000000 AM US/EASTERN US/Eastern EDT -4
The correct time zone is now in the database. Let's test reading this with the following Java:
System.out.println("cal= " + theDateTime);
System.out.println("date= " + theDateTime.getTime());
System.out.println("millis= " + theDateTime.getTimeInMillis());
System.out.println("zone= " + theDateTime.getTimeZone());
This provides the following results:
cal= java.util.GregorianCalendar[...]
date= Sun Oct 29 01:00:00 EST 2006
millis= 1162101600000
zone= sun.util.calendar.ZoneInfo[id="US/Eastern",...]
The TimeZone object is correct since we are using the US/Eastern regional time zone, but the millis are wrong which makes the time EST instead of EDT. The millis should be 1162098000000.
The conversion from java.util.Calendar to TIMESTAMPTZ loses the actual offset when setting to a regional time zone. It can maintain this info by specifying it explicitly.
The conversion from TIMSTAMPTZ to java.util.Calendar also loses the actual offset even if the correct offset is in the database.
Has anyone else encountered this conversion problem? It appears to be a conversion problem in both directions. I know that the Calendar is lenient by default and will assume Standard Time if time is entered during the repeated 1 o'clock hour at the end of Daylight Saving Time, but the Calendars we are using are explicit in their time, so this would be classified as data corruption.
Nik

Opened an SR. Looks like there is a problem with conversion either in TopLink or in JDBC.

Converting httpSession creation time to Date format

I have the need to convert the value returned from httpSession.getCreationTime() to a Date format. The value returned from getCreationTime is long. I need to parse this value into 2 other fields. The first needs to be in year, month, day format. The second must give me the time in hours, minutes, seconds and milliseconds. Thanks in advance for any help you can give me.

Simple:Date date = new Date(httpSession.getCreationTime())

ADF DVT's time Axis Date Format

Hi, I've been working with DVT line graph and bar graph.
Was able to display details and apply time selector.
The details that can be displayed in the graph is dynamic, meaning the number of bars or columns that will be displayed in the graph can be smaller or bigger.
I just noticed that the Date Format that appears in the X-Axis is not consistent, sometimes is display the dates as day (01, 02, 03.. etc.) then month under it.
but sometimes the format is "mm/dd/yy". Is there a way to make the date format consistent?
Thanks.

hi experts, any idea please...

Time Zone storage format

Hi,
what will be the field content if the time zone is stored (Attribute of 0BP_PARTNER in CRM) in an ODS. Will it be like EST or GMT+1 ????
Thank you,
Points will be rewarded

it depends on the application server time, In your case its the time zone of the CRM server and the format is HR:MN:SC
Check this:
System and user time zone*********************8
Time zone in BW reports

SUI Time Calendar Date Format and Hours

Hi
In Fusion/HCM Cloud, the calendar in the Time page of SUI is currently displaying the date in the format MM/DD rather than DD/MM as per our user preferences. Does anyone know how to change this or know if it is a server setting?
Also, when booking absence (full day/elapsed time work schedule) the number of hours is showing 1.0 hours on the first and last day of the absence and then 7.0 hours for the other days in the calendar but this isn't configured anywhere. This is showing correctly in the Availability Calendar within My Portrait. Does anyone know where these hours are coming from?
Any ideas appreciated.
Many thanks
Karen

Do you have a Date object or a String object?
If it's a String object, then just use split or replaceAll or substring (whichever you're most comfortable with) to get just the "2007" portion and then Integer.parseInt.
If it's a Date object, then it doesn't have a format, and you can just feed it to a Calendar and get the year.
Other than that was does "doesn't work" mean?

What format of regionName will be supported when setting session time zone?

hi,
the following is from OracleConnection class
public void setSessionTimeZone(java.lang.String regionName)
throws java.sql.SQLException
Set the session time zone.
This method is used to set the session time zone. This method must be invoked before accessing any TIMESTAMP WITH LOCAL TIME ZONE data. Upon invocation of this method, the Jdbc driver sets the session timezone of the connection adnd saves the session timezone so that any TSLTZ data accessed via Jdbc are adjusted using the session timezone.
Parameters:
regionName - Oracle session time zone region name.
Throws:
java.sql.SQLException - if an error occurred.
Since:
9i
getSessionTimeZone
public java.lang.String getSessionTimeZone()
Obtain Oracle session time zone region name.
Returns:
Oracle session time zone region name.
Since:
9i
which regionName will be supported and in what format?
Thanks a lot!

Hello,
You should be able to use the values in
select * from v$timezone_namesor in
http://download.oracle.com/docs/cd/B28359_01/server.111/b28298/applocaledata.htm#i637736

Document date for time zone of user

We have modeled the date of documents 0CREATEDON (document header and item details) to time dimensions of InfoCubes. The 0CREATEDON date reflects the system date i.e. CST. The report user wants sales document based reporting to reflect his/her time zone date.
We have added an additional field to the sales document header extractor that records time zone date of where document was created. This does not exist for document details extractor.
Has anyone come up against this problem? How have you modeled the data to provide such a reporting capability? Is there date conversion routines for reporting that would convert time zone dates?

With ABAP you can use the function "CONVERT TIME ZONE". If you type this in a test-program with se38 and then press F1 while the cursos is on the wordt CONVERT you will get all necessary explanation.
Note: I think that the timezone of the user is available in one of the sy-fields. The daylight savings indicator is available as a sy-field for sure.

2007 US Daylight Savings change time zone support in JDK 1.3

Sun has supported the 2007 US Daylight Savings change in recent versions of its JDKs 1.4 and 1.5. It has made partial Daylight Savings changes to JDK 1.3, but it's not a complete implementation like in 1.4 and 1.5, because there is no support for past/future Daylight Savings rules, only a single current set of Daylight Savings rules per time zone.
Our Java application (running in the America/New_York time zone) seems to be doomed, because the likelihood of upgrading to JDK 1.4/1.5 seems slim (we have to upgrade a third-party product first and success is seeming more and more remote), and Sun claims to be unable to fully implement the Daylight Savings change in JDK 1.3.
If any Sun Java staff can explain the reasons for being unable to implement the change in 1.3 (or at least some kind of workaround that an individual JVM user could enable), please fill me in. Any pointers on cleanly setting up a custom workaround would be valuable too.
If there are other Java users in the same situation, please fill me in on your own plans if you can. Is anybody trying to pressure Sun or other vendors for a solution? Is anybody writing their own custom workaround?
More details....
What we really need is for the default TimeZone in JDK 1.3 (America/New_York on our machines) to work regardless of whether the date/time being checked is pre-2007 or post-2007. In particular, getOffset and inDaylightTime should work for both 2006 dates and 2007 dates. The JDK should return the correct values for 2006 dates, as well as the correct values for the 2007 US DST extension dates (03/12/2007-04/02/2007 and 10/29/2007-11/05/2007). This would enable parsing and formatting using SimpleDateFormat to work correctly as well. The TimeZone and SimpleDateFormat APIs are used throughout our application.
JDK 1.3.1_19 has an interesting workaround that depends on the current system time. Prior to Jan 1 2007, it will handle 2006 dates correctly but 2007 dates wrong. After Jan 1 2007, it will handle 2007 dates correctly but 2006 dates wrong. Either way, it is always wrong for some dates.
JDK 1.4.2_13 and 1.5.0_09 both handle 2006 and 2007 dates correctly.
If JDK 1.3 will never work for 2006 and 2007 dates, then I am contemplating two workarounds:
1. Set the default TimeZone to a custom implementation as soon after JVM startup as possible.
2. Avoid the default TimeZone entirely, changing our application code to rely on explicit custom TimeZones.
Prior related Java Forum topics:
* http://forum.java.sun.com/thread.jspa?forumID=31&threadID=645874 (Java Essentials - Java Programming) winds up referencing the JDK 1.4 patch as a solution, and there is some discussion about how future/historic dates affect applications
* http://forum.java.sun.com/thread.jspa?forumID=481&threadID=735038 (Deploying - Java Upgrade) just talks about 1.4 and 1.5 patches
* http://forum.java.sun.com/thread.jspa?forumID=481&threadID=717268 (Deploying - Java Upgrade) also just talks about 1.4 and 1.5 patches
* http://forum.java.sun.com/thread.jspa?forumID=37&threadID=703214 (Specifications - Java Virtual Machine (JVM)) also just talks about 1.4 and 1.5
Related Sun Java Bug Database bugs:
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6471271 reports the same issue with 1.3.1_19 that I am seeing and the reporter makes the same clarification, that past/future dates don't work at all still. Sun seems to indicate that it will not fix this in 1.3.1, and the 1.3.1_19 "hack" is it for 1.3.1.
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6391777 refers to updates in 1.3.1_18 to address Australia DST changes, and also indicates that past/future dates (or "historic" dates) won't work at all. It gives a little more rationale behind the difficulty of implementing this for 1.3.1.
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4257314 refers to the fixes in 1.4 to support historic DST dates.
Other articles:
* Sun Java article http://java.sun.com/developer/technicalArticles/Intl/USDST/ refers to 1.3.1_18 as "resolving" the DST issue - this is misleading because the solution in 1.3.1_18 is not complete like that in 1.4 or 1.5
* Server Side article http://www.theserverside.com/news/thread.tss?thread_id=42212 refers to fixes in 1.4 and 1.5 for the DST issue, and the discussion about 1.3 doesn't lead anywhere
Thanks for any info or advice available,
Jim

Hi KBarney
I think u have the correct data file. to make sure see the "zi" dir is backed up in ur java lib folder or not.
if u have suspicion than run the tzupdater tool again.
this tool must be run for each jre/java version on your machine separately.
I tried this on 1.4.2.13 and not on 1.5.0.10. here is the result:
C:\Program Files\Java\j2re1.4.2_13\bin>java -jar c:\tzupdater\tzupdater2006p\tzu
pdater.jar -t -v
java.home: C:\Program Files\Java\j2re1.4.2_13
java.vendor: Sun Microsystems Inc.
java.version: 1.4.2_13
JRE time zone data version: tzdata2006p
Embedded time zone data version: tzdata2006p
Validating the time zone data
Validation complete
C:\tzupdater\tzupdater2006p>java -jar tzupdater.jar test verbose
java.home: C:\Program Files\Java\jre1.5.0_10
java.vendor: Sun Microsystems Inc.
java.version: 1.5.0_10
JRE time zone data version: tzdata2006k
Embedded time zone data version: tzdata2006p
Validating the time zone data
/data/tzdata2006p.test:990: test failed: America/Managua
/data/tzdata2006p.test:1465: test failed: America/Havana
/data/tzdata2006p.test:1466: test failed: America/Havana
/data/tzdata2006p.test:1847: test failed: Cuba
/data/tzdata2006p.test:1848: test failed: Cuba
/data/tzdata2006p.test:2024: test failed: America/Campo_Grande
/data/tzdata2006p.test:2026: test failed: America/Campo_Grande
/data/tzdata2006p.test:2028: test failed: America/Campo_Grande
/data/tzdata2006p.test:2030: test failed: America/Campo_Grande
/data/tzdata2006p.test:2032: test failed: America/Campo_Grande
/data/tzdata2006p.test:2034: test failed: America/Campo_Grande
/data/tzdata2006p.test:2036: test failed: America/Campo_Grande
/data/tzdata2006p.test:2038: test failed: America/Campo_Grande
/data/tzdata2006p.test:2040: test failed: America/Campo_Grande
/data/tzdata2006p.test:2046: test failed: America/Cuiaba
/data/tzdata2006p.test:2048: test failed: America/Cuiaba
/data/tzdata2006p.test:2050: test failed: America/Cuiaba
/data/tzdata2006p.test:2052: test failed: America/Cuiaba
/data/tzdata2006p.test:2054: test failed: America/Cuiaba
/data/tzdata2006p.test:2056: test failed: America/Cuiaba
/data/tzdata2006p.test:2058: test failed: America/Cuiaba
/data/tzdata2006p.test:2060: test failed: America/Cuiaba
/data/tzdata2006p.test:2062: test failed: America/Cuiaba
/data/tzdata2006p.test:2471: test failed: America/Montevideo
/data/tzdata2006p.test:2472: test failed: America/Montevideo
/data/tzdata2006p.test:2475: test failed: America/Montevideo
/data/tzdata2006p.test:2476: test failed: America/Montevideo
/data/tzdata2006p.test:2479: test failed: America/Montevideo
/data/tzdata2006p.test:2480: test failed: America/Montevideo
/data/tzdata2006p.test:2483: test failed: America/Montevideo
/data/tzdata2006p.test:2484: test failed: America/Montevideo
/data/tzdata2006p.test:2487: test failed: America/Montevideo
/data/tzdata2006p.test:2494: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2496: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2498: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2500: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2502: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2504: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2506: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2508: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2510: test failed: America/Sao_Paulo
/data/tzdata2006p.test:2516: test failed: BET
/data/tzdata2006p.test:2518: test failed: BET
/data/tzdata2006p.test:2520: test failed: BET
/data/tzdata2006p.test:2522: test failed: BET
/data/tzdata2006p.test:2524: test failed: BET
/data/tzdata2006p.test:2526: test failed: BET
/data/tzdata2006p.test:2528: test failed: BET
/data/tzdata2006p.test:2530: test failed: BET
/data/tzdata2006p.test:2532: test failed: BET
/data/tzdata2006p.test:2537: test failed: Brazil/East
/data/tzdata2006p.test:2539: test failed: Brazil/East
/data/tzdata2006p.test:2541: test failed: Brazil/East
/data/tzdata2006p.test:2543: test failed: Brazil/East
/data/tzdata2006p.test:2545: test failed: Brazil/East
/data/tzdata2006p.test:2547: test failed: Brazil/East
/data/tzdata2006p.test:2549: test failed: Brazil/East
/data/tzdata2006p.test:2551: test failed: Brazil/East
/data/tzdata2006p.test:2553: test failed: Brazil/East
/data/tzdata2006p.test:3451: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3452: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3453: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3454: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3455: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3456: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3457: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3458: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3459: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3460: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3461: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3462: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3463: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3464: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3465: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3466: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3467: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3468: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3469: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3470: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3471: time zone not found: Europe/Podgorica
/data/tzdata2006p.test:3791: test failed: ART
/data/tzdata2006p.test:3814: test failed: Africa/Cairo
/data/tzdata2006p.test:3844: test failed: Asia/Amman
/data/tzdata2006p.test:3848: test failed: Asia/Amman
/data/tzdata2006p.test:3852: test failed: Asia/Amman
/data/tzdata2006p.test:3856: test failed: Asia/Amman
/data/tzdata2006p.test:3860: test failed: Asia/Amman
/data/tzdata2006p.test:3887: test failed: Asia/Damascus
/data/tzdata2006p.test:3908: test failed: Asia/Gaza
/data/tzdata2006p.test:3911: test failed: Asia/Gaza
/data/tzdata2006p.test:3915: test failed: Asia/Gaza
/data/tzdata2006p.test:3919: test failed: Asia/Gaza
/data/tzdata2006p.test:3923: test failed: Asia/Gaza
/data/tzdata2006p.test:4035: test failed: Egypt
/data/tzdata2006p.test:4901: test failed: Australia/Perth
/data/tzdata2006p.test:4902: test failed: Australia/Perth
/data/tzdata2006p.test:4905: test failed: Australia/Perth
/data/tzdata2006p.test:4906: test failed: Australia/Perth
/data/tzdata2006p.test:4909: test failed: Australia/Perth
/data/tzdata2006p.test:4910: test failed: Australia/Perth
/data/tzdata2006p.test:4914: test failed: Australia/West
/data/tzdata2006p.test:4915: test failed: Australia/West
/data/tzdata2006p.test:4918: test failed: Australia/West
/data/tzdata2006p.test:4919: test failed: Australia/West
/data/tzdata2006p.test:4922: test failed: Australia/West
/data/tzdata2006p.test:4923: test failed: Australia/West
Validation tests failed.
-Ranjan

Implicit date format conversion of report column

Hello,
The following expression defines date format for report column implicitly and doesn't reflect FSP_LANGUAGE_PREFERENCE with language independent format mask of the column attribute anymore:
decode(end_date, to_date('31.12.2047', 'dd.mm.yyyy'), null, end_date) closed
end_date is of TIMESTAMP(0) WITH LOCAL TIME ZONE type, format mask of the column attribute: DS TS
Is it expected behavior?
Thanks

Edward Shevtsov wrote:
Hello,
The following expression defines date format for report column implicitly and doesn't reflect FSP_LANGUAGE_PREFERENCE with language independent format mask of the column attribute anymore:
decode(end_date, to_date('31.12.2047', 'dd.mm.yyyy'), null, end_date) closed
end_date is of TIMESTAMP(0) WITH LOCAL TIME ZONE type, format mask of the column attribute: DS TS
Is it expected behavior?
ThanksThe reason might be that you compare different datatypes in the SQL statement. The output of decode depends on those parameters.
You can cast the column to a specific datatype or you make sure that your wanted datatype is used during the decode.
example
decode(end_date, to_timestamp_tz('31.12.2047', 'dd.mm.yyyy'), null, end_date) closed
or
cast(decode(end_date, to_date('31.12.2047', 'dd.mm.yyyy'), null, end_date) as timestamp(0) with local time zone) closed

Time Zone / Calendar

I have tried to use the timezone/calendar functionalities
to calculate my local time and the GMT time. This works perfectly well
on my 2 home machines, however, on the work machine the local time always comes back with the GMT time 9ie offset of zero. The windows time and zone is set correctly. Is there a reason why this happens ? The machine is networked and has mulitple userids defined for it. Is there something
special that needs to be done ? Where does java read the time from ?
Thanks in advance Br /David.

The class java.text.DateFormat (java.text.SimpleDateFormat) is recommended in this case. Try this.
import java.util.*;
import java.text.*;
public final class ESTtoGMT{
public static void main(String[] args) throws java.lang.Exception{
DateFormat sdf = new SimpleDateFormat("yyyy-MM-dd G HH:mm:ss.SSS z");//pattern is arbitrarily chosen here
Calendar cal = Calendar.getInstance(new SimpleTimeZone(-5*60*60*1000,"EST"));//this requires DST (dailight saving time) adjustment manually
sdf.setCalendar(cal);
Date temptime = new Date(); // this part is independent from time zone
String formatted = sdf.format(temptime);
System.out.println(formatted);
cal = Calendar.getInstance(new SimpleTimeZone(0,"UTC"));// or "GMT"
sdf.setCalendar(cal);
formatted = sdf.format(temptime);
System.out.println(formatted);
}

TIME-ZONE date format..

Similar Messages

Maybe you are looking for