Same problem in IE 8.0.7601.17514 and Chrome 25.0.1364.152
Announcement
Collapse
No announcement yet.
X
-
We see an issue where the baseDate is not correctly reset when Now is selected from the picklist - we're looking at that.
In the meantime, can you confirm that just clearing out the value before typing $now makes that work for you? (your sample code would need updating to include both $today in the presets and to cater for either startDate or endDate being null in your changed handler)Last edited by Isomorphic; 12 Mar 2013, 06:28.
Comment
-
Originally posted by Isomorphic View PostWe see an issue where the baseDate is not correctly reset when Now is selected from the picklist - we're looking at that.
In the meantime, can you confirm that just clearing out the value before typing $now makes that work for you?
Exception in case anyone is interested.
Code:Uncaught exception escaped : com.google.gwt.event.shared.UmbrellaException Exception caught: java.lang.String cannot be cast to java.util.Date See the Development console log for details. Register a GWT.setUncaughtExceptionHandler(..) for custom uncaught exception handling
Comment
-
Further changes have been made to address the "Now" issue - note, however, that actually typing the value "$now" is not documented support - you should type "Now".
It's not clear why you're calling setDateParser(), or why your inline comment says that's necessary - internally, this call affects the inputFormat, and that attribute is expected to be a 3-char string that indicates the order of the Day, Month and Year components of a date-string, like "DMY". The net result is an inability to interpret any date-strings you type in.
The warnings you're seeing are a result of your calls to setFieldErrors() - we'll update this thread when that's been addressedLast edited by Isomorphic; 12 Mar 2013, 09:56.
Comment
-
Originally posted by Isomorphic View PostFurther changes have been made to address the "Now" issue - note, however, that actually typing the value "$now" is not documented support - you should type "Now".
It's not clear why you're calling setDateParser(), or why your inline comment says that's necessary - internally, this call affects the inputFormat, and that attribute is expected to be a 3-char string that indicates the order of the Day, Month and Year components of a date-string, like "DMY". The net result is an inability to interpret any date-strings you type in
http://forums.smartclient.com/showth...t=25160&page=2
Comment
-
We told you:
Did you supply a corresponding parser in DateUtil for your custom date format? If you haven't, that would explain the problem.
Comment
-
Originally posted by Isomorphic View PostWe told you:
This advice is correct. The problem is, your parser is too strict and rejects valid input. If you just setInputFormat() to the correct MDY order, the default parser can parse your custom format.
I figured out that the fields are formatted in this order for two RelativeDateItems:
1. Start Picker
2. End Picker
3. Start Calc Date Field
4. End Calc Date Field
Code:
Code:private void changeDateFormat() { DateUtil.setShortDatetimeDisplayFormatter(new DateDisplayFormatter() { @Override public String format(Date date) { if(date == null) { return null; } else { // When this class is initially created, it will go through // and format the drop-down and then the text entry fields // We track that formatting using the enums below // The drop-downs are formatted first and then the // calculated date field is formatted. if (dateFields == DateFields.FIELD1_NO_UTC) { synchronized(theLock) { dateFields = DateFields.FIELD2_NO_UTC; } final DateTimeFormat dateFormatter = DateTimeFormat.getFormat(DATE_FORMAT); String format = dateFormatter.format(date); return format; } if (dateFields == DateFields.FIELD2_NO_UTC) { synchronized(theLock) { dateFields = DateFields.FIELD3_UTC; } final DateTimeFormat dateFormatter = DateTimeFormat.getFormat(DATE_FORMAT); String format = dateFormatter.format(date); return format; } if (dateFields == DateFields.FIELD3_UTC) { synchronized(theLock) { dateFields = DateFields.FIELD4_UTC; } final DateTimeFormat dateFormatter = DateTimeFormat.getFormat(DATE_FORMAT_W_ZONE); String format = dateFormatter.format(date, TimeZone.createTimeZone(0)); return format; } else { synchronized(theLock) { dateFields = DateFields.FIELD1_NO_UTC; } final DateTimeFormat dateFormatter = DateTimeFormat.getFormat(DATE_FORMAT_W_ZONE); String format = dateFormatter.format(date, TimeZone.createTimeZone(0)); return format; } } } }); // It is a requirement that we implement a custom date parser // or the onChanged event will not fire. // The parser is fired twice when selecting or changing the // date via text entry or via the calendar object // The reason it is fired twice is so the text can be formatted and the // calculated date field to the right can be formatted. // We want the calculated date to the right to always show UTC DateUtil.setDateParser(new DateParser() { @Override public Date parse(String dateString) { if (dateFields == DateFields.FIELD3_UTC || dateFields == DateFields.FIELD4_UTC) { // Reset synchronized(theLock) { dateFields = DateFields.FIELD1_NO_UTC; } } // This condition means our initial selection was formatted // by setShortDatetimeDisplayFormatter and now it needs to be // parsed. // The sequence is always setShortDatetimeDisplayFormatter then // setDateParser when you change the date if (dateFields == DateFields.FIELD2_NO_UTC) { final DateTimeFormat format = DateTimeFormat.getFormat(DATE_FORMAT); synchronized(theLock) { dateFields = DateFields.FIELD3_UTC; } return format.parse(dateString); } else { // Alter the date that has come in without UTC and then make // it UTC. // This will call setShortDatetimeDisplayFormatter again. final DateTimeFormat format = DateTimeFormat.getFormat(DATE_FORMAT); Date preFinalDate = format.parse(dateString); final DateTimeFormat dateFormatter = DateTimeFormat.getFormat(DATE_FORMAT_W_ZONE); String finalDateString = dateFormatter.format(preFinalDate, TimeZone.createTimeZone(0)); Date finalDate = dateFormatter.parse(finalDateString); // Set this for when it re-enters // setShortDatetimeDisplayFormatter synchronized(theLock) { dateFields = DateFields.FIELD4_UTC; } return finalDate; } } }); }
Comment
-
The warnings you're seeing are a result of your calls to setFieldErrors() - we'll update this thread when that's been addressed
I suppose I could create a custom validator, but that would still use setFieldErrors.Last edited by bwilkins30; 12 Mar 2013, 12:19.
Comment
-
You can set the system-wide default display timezone on DateUtil. Writing your own formatter that forces display timezone to UTC while leaving the framework unaware of this would have the result you're seeing. See also the Date and Time Format and Storage overview.
About setFieldErrors(), as previously indicated we plan to eliminate the warning.
Comment
-
Originally posted by Isomorphic View PostYou can set the system-wide default display timezone on DateUtil. Writing your own formatter that forces display timezone to UTC while leaving the framework unaware of this would have the result you're seeing. See also the Date and Time Format and Storage overview.
e.g.,
Code:private void changeDateFormat() { DateUtil.setDefaultDisplayTimezone("-00:00"); DateUtil.setShortDatetimeDisplayFormatter(new DateDisplayFormatter() { public String format(Date date) { if(date == null) { return null; } else { final DateTimeFormat dateFormatter = DateTimeFormat.getFormat(DATE_FORMAT); return dateFormatter.format(date); } } }); // It is a requirement that we implement a custom date parser or the onChanged event // will not fire. // DateUtil.setDateParser(new DateParser() // { // public Date parse(String dateString) // { // final DateTimeFormat format = DateTimeFormat.getFormat(DATE_FORMAT); // return format.parse(dateString); // // } // }); }
Last edited by bwilkins30; 12 Mar 2013, 12:40.
Comment
-
If you want the text "UTC" shown after the date, you can still do that with a custom formatter and parser pair. Just make sure your formatter / parser correctly handles timezone parsing (very tricky - see Date Format and Storage overview previously mentioned).
You can test whether they are correct by just disabling them, at which point you won't see the hours shift as you currently do.
Comment
-
Originally posted by Isomorphic View PostIf you want the text "UTC" shown after the date, you can still do that with a custom formatter and parser pair. Just make sure your formatter / parser correctly handles timezone parsing (very tricky - see Date Format and Storage overview previously mentioned).
You can test whether they are correct by just disabling them, at which point you won't see the hours shift as you currently do.
But now I have the problem of the text UTC-4 showing in my picker field. I only want it in the calculated date field. I want the picker field to show in local time. It seems DateUtil makes a global, system-wide change like you said, so that's why I went to the custom formatting code I pasted earlier. I don't know if SmartGWT can do this or not. It seems like it just formats dates in whatever format you tell it to originally, without regard for what field will contain the date. I wouldn't expect it to know without something custom being done, however.
Comment
-
Just to be very clear, you're hoping for:
1. text entry to be interpreted as local time, with no timezone indicator
2. picking from the date chooser or relative dates to be interpreted as local time
2. the calculated date to be shown as UTC with a "UTC" suffix added - and no UTC dates or UTC suffix anywhere else in the system, just this one control.
Please confirm, or be very clear about the exact behavior you want.
Comment
-
Originally posted by Isomorphic View PostJust to be very clear, you're hoping for:
1. text entry to be interpreted as local time, with no timezone indicator
2. picking from the date chooser or relative dates to be interpreted as local time
2. the calculated date to be shown as UTC with a "UTC" suffix added - and no UTC dates or UTC suffix anywhere else in the system, just this one control.
Please confirm, or be very clear about the exact behavior you want.
When I say picker, I mean text entry - yes
1. Text Entry in Local Time
2. If Text Entry is say, Now, then just show Now in Text Entry and calculate date field with Now (e.g. 12.Mar.2013 9:02 UTC).
3. Picking from the date chooser (what I called calendar), show text entry in local time (e.g. 12.Mar.2013 5:02), calculate date field in UTC (e.g. 12.Mar.2013 9:02 UTC)
Bottom line, the calculate date field always in UTC formatted as 12.Mar.2013 9:02 UTC and text entry (picklist or whatever it is called) 12.Mar.2013 5:02
I will have no idea what the time zone offset of the user will be, so it has to be flexible.
Comment
Comment