On Nov 19, 2013, at 12:12 PM, Samuel Pelletier <[email protected]> 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 calendar representation is time > zone dependant. > > I think the LocalDate and LocalTime can work with my fix LocalDate and DateTime works based on a modification of the test code I attached. Value in == value out. Feel free to simplify it if the Calendar stuff is not required. Just don’t break it :-) I use those two. > but for LocalDateTime, I would need to add a double time zone adjustment to > UTC or GMT; convert to UTC on save and from UTC on read. > > LocalDate and LocalTime seems more easily handled but I need to test. > > I try to avoid timestamp except for usage like log entry timestamp where we > want to know when something occurred. For local time, I prefer string > columns, their behaviour is always predictable. > > Samuel 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. is_active “TRUE” “FALSE” “F” “YES" “MAYBE” happy_hour “18:00:00” “99:99:99” “noon" “Gerald” “CUSTOM" I prefer to use the correct value type for the value being stored. Correct value types prevent all sorts of clever tricks. You see that preference of mine reflected in the existing prototypes. For postgres at least, the external types are the correct ones for the datastore. LocalTime uses time. LocalDate uses date. LocalDateTime and DateTime use timestamp. For other DBs, IDGAF so much :-) _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
