Dan:
Probably no one is going to be able to tell what you mean by migrations
"complaining." Do you have a stack trace or other console output? I ran
BugTracker for the first time yesterday against FrontBase and migrations worked.
I'm not sure what you mean by "correction?"
Tim Worman
UCLA GSE&
Hi Paul,
I just saw this (late to the party). I solved this for one of our apps in a
way very similar to what you have there:
public class XSLURIResolver implements URIResolver {
public Source resolve(String href, String base) throws
TransformerException {
StringBuffer
On 02/10/2010, at 10:01 AM, Chuck Hill wrote:
>>> I was recently trying to configure a prototype for Joda-Time LocalDate, but
>>> the Joda-Time classes don't have factory methods, and are declared final,
>>> as discussed recently that last thread.
>>
>> I'm using basically the sample code Henri
On Oct 1, 2010, at 5:26 PM, Paul Hoadley wrote:
> On 02/10/2010, at 8:50 AM, Roger Marshall wrote:
>
>> "Dates (1-day resolution) redux"
>> http://lists.apple.com/archives/webobjects-dev/2010/Aug/thrd2.html#00132
>>
>> How are people persisting their Joda-Time values?
>
> I'm using Postgr
On 02/10/2010, at 8:50 AM, Roger Marshall wrote:
> "Dates (1-day resolution) redux"
> http://lists.apple.com/archives/webobjects-dev/2010/Aug/thrd2.html#00132
>
> How are people persisting their Joda-Time values?
I'm using PostgreSQL's DATE type (4 bytes, no time of day, 1 day resolution).
Hey!
On 1/Oct/2010, at 11:54 AM, Ramsey Gurley wrote:
> D'oh! I'll go back to *not* thinking about dates again. (^_^)
Time is such fun!
> Word to the wise... Chuck Hill is always right.
Indeed! ;-)
M.
___
Do not post admin requests to the list. They
On 02/10/2010, at 7:01 AM, Travis Britt wrote:
> Just chiming in to say Joda totally rocks, and if I'd starting using it two
> years ago rather than one year ago I'd have more hair left.
FWIW, I've been using Joda Time since the last thread on this issue back in
August. Specifically, the Local
Greetings all,
Oh silly me. The old WO install database script. Although, migrations seems
to complain about the Derby database generated by the script, but I think I can
generate the SQL otherwise and hopefully adjust the bug.sql. Does the WOnder
or WOInstaller make such a correction, or is
didn't 5.4 add adaptorValueConversionClassName in addition to the
adaptorValueConversionMethodName that lets you get around that limitation? the
other option is add wrapper methods (in and out) for you EO accessors.
ms
On Oct 1, 2010, at 7:20 PM, Roger Marshall wrote:
> Previously on "Date Hat
Previously on "Date Hate":
"Date-Only NSTimestamps"
http://lists.apple.com/archives/webobjects-dev/2008/Jan/threads.html#00023
"Recording and looking up dates, when day-wide precision is required"
http://lists.apple.com/archives/webobjects-dev/2008/Dec/thrd7.html#00626
What do you guys do for formatting DateTime in something like a
WOTextField? Convert to date/NSTimestamp? Just browsing the javadocs,
I don't see any subclass of java.text.Format in there.
Ramsey
On Oct 1, 2010, at 5:31 PM, Travis Britt wrote:
Just chiming in to say Joda totally rocks, and
yeah it doesn't care
ms
On Oct 1, 2010, at 5:33 PM, Kieran Kelleher wrote:
> I can't confirm it since I have never regressed or gone backwards in the
> progress bar! . the progress bar is Wonder's AjaxProgressBar with a
> subclass of Wonder's AjaxProgress attached to it, so you would need
I can't confirm it since I have never regressed or gone backwards in the
progress bar! . the progress bar is Wonder's AjaxProgressBar with a
subclass of Wonder's AjaxProgress attached to it, so you would need to check
the source. Just quickly glancing at the source, I think it might, but no
Just chiming in to say Joda totally rocks, and if I'd starting using it two
years ago rather than one year ago I'd have more hair left.
tb
On Oct 1, 2010, at 4:46 PM, Ramsey Gurley wrote:
> Sounds like I might be a fan soon (^_^)
>
> Ramsey
>
> On Oct 1, 2010, at 4:41 PM, Mike Schrag wrote:
>
On 2010-10-01, at 15:01 , Kieran Kelleher wrote:
> Hi Louis,
>
> Sorry, I haven't had a chance to commit all of this functionality to Wonder
> yet ... it had some dependencies with respect to error handling that I
> wanted to deal with without unnecessarily bringing in my whole error handl
Sounds like I might be a fan soon (^_^)
Ramsey
On Oct 1, 2010, at 4:41 PM, Mike Schrag wrote:
yeah it's kind of a big deal to them ...
"Joda-Time makes heavy use of the immutability design pattern, and
all immutable classes in Joda-Time are thread-safe. Many mutable
classes whose instance
yeah it's kind of a big deal to them ...
"Joda-Time makes heavy use of the immutability design pattern, and all
immutable classes in Joda-Time are thread-safe. Many mutable classes whose
instances are not likely to be shared are not thread-safe, and are documented
as such."
On Oct 1, 2010, at
On Oct 1, 2010, at 3:25 PM, Ray Kiddy wrote:
On Oct 1, 2010, at 11:54 AM, Ramsey Gurley wrote:
And, I'm wrong
GregorianCalendar gc = new
GregorianCalendar(2009,2,13,14,36,45);
TimeZone pst = TimeZone.getTimeZone( "PST" );
TimeZone est = TimeZone.getTimeZone( "EST" )
On Oct 1, 2010, at 1:02 PM, Ray Kiddy wrote:
On Oct 1, 2010, at 9:00 AM, Ramsey Gurley wrote:
On Oct 1, 2010, at 11:33 AM, Ray Kiddy wrote:
And lots of people have talked, over the years, about a
NSWallClockTime/Date class, one that could capture the situation
where I look at the cloc
On Oct 1, 2010, at 12:56 PM, Ramsey Gurley wrote:
>
> So, it does used fixed gregorian units... until you give it a timezone. Once
> that happens, the units are recalculated when updating the time zone, not the
> time.
>
> *facepalm*
Java. Dates. Hate'm.
smime.p7s
Description: S/MIME cry
Erm... I think we may both be 'right' this time (^_^)
GregorianCalendar gc = new
GregorianCalendar(2009,2,13,14,36,45);
GregorianCalendar gc1 = new
GregorianCalendar(2009,2,13,14,36,45);
TimeZone pst = TimeZone.getTimeZone( "PST" );
TimeZone est = TimeZone.get
On Oct 1, 2010, at 11:54 AM, Ramsey Gurley wrote:
> And, I'm wrong
>
>GregorianCalendar gc = new GregorianCalendar(2009,2,13,14,36,45);
>TimeZone pst = TimeZone.getTimeZone( "PST" );
>TimeZone est = TimeZone.getTimeZone( "EST" );
>gc.setTimeZone( pst );
>
On Oct 1, 2010, at 11:54 AM, Ramsey Gurley wrote:
> And, I'm wrong
>
>GregorianCalendar gc = new GregorianCalendar(2009,2,13,14,36,45);
>TimeZone pst = TimeZone.getTimeZone( "PST" );
>TimeZone est = TimeZone.getTimeZone( "EST" );
>gc.setTimeZone( pst );
>
Hi Louis,
Sorry, I haven't had a chance to commit all of this functionality to Wonder yet
... it had some dependencies with respect to error handling that I wanted
to deal with without unnecessarily bringing in my whole error handling classes
.. and I have just been so busy (aka very lo
And, I'm wrong
GregorianCalendar gc = new
GregorianCalendar(2009,2,13,14,36,45);
TimeZone pst = TimeZone.getTimeZone( "PST" );
TimeZone est = TimeZone.getTimeZone( "EST" );
gc.setTimeZone( pst );
System.out.println(gc.getTimeInMillis());
gc.s
I think formatting it for display brings the timezone into play, but I am not
sure. And not, mutable is not good for EOF.
On Oct 1, 2010, at 10:29 AM, Ramsey Gurley wrote:
> My understanding of the GregorianCalendar class is that unlike Date, it
> stores the gregorian units as the fixed value
My understanding of the GregorianCalendar class is that unlike Date,
it stores the gregorian units as the fixed value and the value of
getTime is calculated based on the units and the time zone. So it
doesn't matter if you set the timezone to Fiji time or PST, it will
still tell you 12/31/
> It seems better to me to have a class that has a very abstract concept of the
> wall time/date. Can an instance of this be turned into a GregorianCalendar
> object? Yes, with the other necessary information provided. Should it just
> guess? Well, that is what is causing problems now, so maybe
On Oct 1, 2010, at 9:55 AM, Mike Schrag wrote:
>> And lots of people have talked, over the years, about a NSWallClockTime/Date
>> class, one that could capture the situation where I look at the clock and
>> see a "2:00" and I want to discuss it with someone else who can look at
>> another cloc
I use joda all the time - their formatters are thread-safe!
On Oct 1, 2010, at 12:57 PM, Chuck Hill wrote:
>
> On Oct 1, 2010, at 9:55 AM, Mike Schrag wrote:
>
>>> And lots of people have talked, over the years, about a
>>> NSWallClockTime/Date class, one that could capture the situation where
On Oct 1, 2010, at 9:00 AM, Ramsey Gurley wrote:
>
> On Oct 1, 2010, at 11:33 AM, Ray Kiddy wrote:
>>
>> And lots of people have talked, over the years, about a NSWallClockTime/Date
>> class, one that could capture the situation where I look at the clock and
>> see a "2:00" and I want to disc
The problem is that GregorianCalendar still has a time zone which is what most
people seem to want to avoid with date only values. Otherwise, really, you
need a geographically referenced point in time.
On Oct 1, 2010, at 9:00 AM, Ramsey Gurley wrote:
>
> On Oct 1, 2010, at 11:33 AM, Ray Kid
> And lots of people have talked, over the years, about a NSWallClockTime/Date
> class, one that could capture the situation where I look at the clock and see
> a "2:00" and I want to discuss it with someone else who can look at another
> clock, regardless of what time zone they are in. Does any
Le 2010-10-01 à 11:33, Ray Kiddy a écrit :
>
> On Sep 30, 2010, at 12:12 PM, Mike Schrag wrote:
>
>> Calendar dates should not be represented by NSTimestamp. The Date
>> prototype is wrong for using it IMHO.
>
> i couldn't agree more. but where do we go from here ?
>
>>>
On Oct 1, 2010, at 11:33 AM, Ray Kiddy wrote:
On Sep 30, 2010, at 12:12 PM, Mike Schrag wrote:
Calendar dates should not be represented by NSTimestamp. The
Date prototype is wrong for using it IMHO.
i couldn't agree more. but where do we go from here ?
1) leave the mysql date prototype
Hi,
Integrated the GenericAjaxLongResponsePage from the WOWODC2010
repository into my stuff and I love it. I'd like some clarification on 2 issues
Background: My long task has to be performed in 2 phases, Phase one goes
through a large array and reduces in into a smaller array that is f
On Sep 30, 2010, at 12:12 PM, Mike Schrag wrote:
> Calendar dates should not be represented by NSTimestamp. The Date
> prototype is wrong for using it IMHO.
i couldn't agree more. but where do we go from here ?
1) leave the mysql date prototype as it is now, broken
37 matches
Mail list logo
