Hi,
The right way to solve the situation is to change the attribute type in your
database for the one that should have been used from start but where not used
because the prototypes where flawed.
You may do it with FrontBase Manager or issue the alter table statements (data
remains intact) lik
I thought about that, but when I did a new Migrate, the generated code was no
different than what it previously was, e.g.
eventTable.newTimestampColumn("c_date_time", false);
However, maybe I need to update the EOGenerator in some way? If so, I'm not
sure where I would go to do
Hi Jeff,
I can remember that there was a fix for FrontBase prototypes some time ago. A
search within the commit messages reveals a commit from Samuel dating back to
21.11.2013 where the prototype was changed from TIMESTAMP to TIMESTAMP WITH
TIME ZONE. What type are your table columns in FrontBa
A little more digging on this...
Down in com.webobjects.jdbcadaptor._FrontBasePlugin class, if I comment out
line 1825 in the formatValueForAttribute function (as shown below) , I am able
to save the Timestamp value in the database, so it looks like Frontbase doesn't
like the way this function
Samuel, Ramsey,
Hi All,
I’m using Frontbase, and an EOObject with a field defined with the Prototype
jodaLocalDateTime has stopped working. Since I recently updated my Wonder
frameworks I suspect that has something to do with it.
Looking at the SLQ produced for an INSERT on a machine sti
Ramsey,
My tests with different databases (mySql, PostgreSql and FrontBase) are now all
OK. I inserted and read back data with the 4 types with different time zone on
my machine successfully. I needed to make sure the data was saved in an
expected way for compatibility with others users of the
On Nov 21, 2013, at 10:02 AM, Samuel Pelletier wrote:
> Ramsey,
>
> The current code in the master branch is broken for LocalTime AND
> LocalDateTime unless your current time zone is GMT.
I think it’s broken for GMT too on both of those.
> I do not think the code should depend on the current
Ramsey,
The current code in the master branch is broken for LocalTime AND LocalDateTime
unless your current time zone is GMT. I do not think the code should depend on
the current application server time zone. Here is my very simple test code.
The good news is I think my current fix will not br
On Nov 19, 2013, at 4:43 PM, Ramsey Gurley wrote:
> I hate strings that need to conform to a certain format. It never fails.
> Someone always inserts something poorly formatted or a F'in magic string in
> the column.
Amen, brother!
Afreakin’men.
Dave
—
WebObjects
On Nov 19, 2013, at 12:12 PM, Samuel Pelletier wrote:
> The code in ValueFactory.java does nothing, a simple return new
> LocalDateTime(value) does the same thing.
>
> The problem with the LocalDateTime is the SQL timestamp is by definition an
> absolute point in time and that means it's cale
The code in ValueFactory.java does nothing, a simple return new
LocalDateTime(value) does the same thing.
The problem with the LocalDateTime is the SQL timestamp is by definition an
absolute point in time and that means it's calendar representation is time zone
dependant.
I think the LocalDate
Yep, you’re right. LocalTime and LocalDateTime are broken. And I still hate
java dates :-) It should be the same in and out.
When you fix it, please include a unit test for ERXTest in the pull request
demonstrating it is fixed no matter the time zone.
Something like
public void testValueC
In Wonder 6.1, I see:
ValueFactory.java
public static LocalDateTime jodaLocalDateTime(Date value) {
GregorianCalendar gc = new GregorianCalendar(GMT);
gc.setTime(value);
LocalDateTime ldt = new LocalDateTime(gc.getTimeInMillis());
Hi,
This issue confirm my doubts about the way JodaLocalxxx are saved. I have a
branch in my repo with some correction in the Joda time attribute handling, the
conversion in the save and read functions are not symmetric in the actual code.
I also updated the JodaTime lib to latest with updated
JDBC still relies on java.sql.Timestamp, etc, which uses the system's time
zone when saving and loading data. Usually the easiest solution is to set
the default time zone to UTC by adding a VM argument -Duser.timezone=UTC
Then when you need to display date times you can choose a different time
zo
Hello List,
A simple question about a time value (as if any quesiton about webobjects
and time is simple :-)), I have a field I've defined using the
jodaLocalDateTime prototype. I was assuming that if I save the value
2013-11-14T12:00:00.000 to my EO, the database would save exactly that, us
16 matches
Mail list logo
