Re: Date-Only NSTimestamps
Re: Date-Only NSTimestamps
- Subject: Re: Date-Only NSTimestamps
- From: "Mr. Pierre Frisch" <email@hidden>
- Date: Thu, 3 Jan 2008 10:29:40 -0800
Happy new year to you all.
Just a word of caution here.
NSTimeZone is deprecated because it uses an internal copy of the time
zone database. Time zone are not stables, they change on a very
regular basis (If I remember well 2007 had 10 updates and 2006, 16).
If you don't like it talk to your politicians. You should use the Java
TimeZone as they are updated on a more regular basis and your results
will be more accurate.
Because of this, storing any date in local time instead of GMT is
likely to leads to disappointment. There is no guarantee that the time
zone you used to store your date will be the same than the one you
used to retrieve it. I fact there is a good possibility that this will
have changed under your feet. Typically each revision of the JVM
includes a new version of the time zone database. The only safe way of
storing dates is GMT as this is by definition guaranteed not to change.
Cheers
Pierre
--
Pierre Frisch
email@hidden
On Jan 2, 2008, at 23:58, Simon McLean wrote:
It is a problem when the value is saved during DST and then
queried when DST is not in effect (or vice versa).
Aaahh, yes, I remember now. That's the big pain in the butt!
the default time time zone to GMT. But then you get a whole new
world of pain because you have to convert timestamps on the fly
for presenting to your users!
That actually turns out to be fairly easy because you use a common
datetime formatter on the session for all of the user's time
rendering. This can be used bi-directionally for WOTextFields as
well and then it is not too tricky at all to achieve this.
I don't see how this is any different from what WO does already.
NSTimestamps are always in GMT and get formatted to / from the
local timezone. If you set the local timezone to GMT, you avoid
problems with new NSTimestamp, but you still have problems with
dates parsed from user input if you don't want to interpret that as
GMT values. What am I missing?
Good question :-) The new NSTimestamp() is the main problem solved -
including the querying in/out of DST. But let me change the tack a
little...
What if we store the user's literal input at GMT too (so if they put
14:00 we store it at 14:00 GMT) then for the majority of uses there
is no need to change anything on the fly. We can just push and pull
values from the DB and display exactly what we get to the user.
Queries will never go wrong because there are no DST issues. We are
effectively normalising the timezone.
It then becomes an issue if you want to calculate the difference in
time between to points in different time zones (ie. user 1 enters a
date/time in BST and user 2 enters a date/time in EST and you want
to calculate the difference between the 2 literal date/time's). You
could solve this by storing the timezone of each record separately
(i guess just as a the string abbreviation) and having a cover
method which converts the timestamp on the fly:
public NSTimestamp myTimeStamp; // assume it exists and is stored in
GMT.
public String myTimeZone; // assume it exists and is set to the
users timezone.
public NSTimestamp myTimeStampInMyTimeZone() {
GregorianCalendar gc = new GregorianCalendar();
gc.setTime(date);
int day = gc.get(GregorianCalendar.DAY_OF_MONTH);
int mth = gc.get(GregorianCalendar.MONTH) + 1;
int year = gc.get(GregorianCalendar.YEAR);
int hour = gc.get(GregorianCalendar.HOUR_OF_DAY);
int min = gc.get(GregorianCalendar.MINUTE);
int sec = gc.get(GregorianCalendar.SECOND);
NSTimeZone tz = NSTimeZone.timeZoneWithName(myTimeZone, true);
return new NSTimestamp(year, mth, day, hour, min, sec, tz);
}
What else could go wrong ?
Simon
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden