Re: Recording and looking up dates, when day-wide precision is required
Re: Recording and looking up dates, when day-wide precision is required
- Subject: Re: Recording and looking up dates, when day-wide precision is required
- From: "Peter Vandoros" <email@hidden>
- Date: Fri, 2 Jan 2009 11:13:39 +1100 (EST)
- Importance: Normal
See attached file. I hope this helps you out.
Regards
Peter
> The attachment never came (could be list filters). Could you please
> send it to me off list, so I can see what you mean?
>
> Thanks,
> F
>
> On Dec 30, 2008, at 19:21, Peter Vandoros wrote:
>
>> If you store the date in universal time (or logical time as Andrew
>> pointed out) as milliseconds (ie. a long) as i described in my
>> previous email, you are able to display that in any time zone and
>> the "textual" display (using SImpleDateFormat) will be the same.
>> Obviously for this to work, you need to convert the time the user
>> enters into universal time (UTC) when storing the date and then
>> converting it to the user's local time zone when displaying it for
>> the client.
>>
>> I attached a small java app that demonstrates how to convert the
>> date between universal time and user's local time.
>>
>> Regards
>>
>> Peter
>>
>> On 31/12/2008, at 2:19 AM, Florijan Stamenkovic wrote:
>>
>>>
>>> On Dec 30, 2008, at 06:03, Lachlan Deck wrote:
>>>
>>>> Hi there,
>>>>
>>>> On 30/12/2008, at 7:47 PM, Andrew Lindesay wrote:
>>>>
>>>>> I _think_ (correct me if I'm wrong) Florijan would like to store
>>>>> a logical date rather than a timestamp. For example, he would
>>>>> like to store the date 2008-09-28. The requirement being that
>>>>> the same date is applicable to all timezones because it is
>>>>> composited from year/month/day and is thus independent of
>>>>> timezones.
>>>>>
>>>>> An example where this might be useful is to store birthdays.
>>>>
>>>> Right - I think it was Florijan's more elaborate description that
>>>> confused me :-) I thought he was saying he wanted the date to be
>>>> presented according to the user's local timezone whilst at the
>>>> same time he was talking about this need. So I wasn't clear on his
>>>> aims.
>>>
>>> Plus, perhaps you were thinking of a web-app scenario, and that's
>>> not what I am doing. I am working on a JC app, where dates are
>>> transferred to and from the client machine in raw form. So, all the
>>> parsing and formatting happens on the client machine, which could
>>> be anywhere.
>>>
>>>>> For example, a birthday is 1980-08-08. If I should decide to live
>>>>> in Munich for a while (I presently live in Auckland) then the
>>>>> same birthday applies, but if I stored it as a timestamp then it
>>>>> would have shifted to another day while I live in Munich. Hence
>>>>> the difficulty storing these things as timestamps.
>>>>
>>>> Depends when you want your present ;-)
>>>>
>>>> So if you're storing dates in the database (as opposed to
>>>> timestamps) you'll have to normalise them prior to storage. For
>>>> display you'll need a custom formatter.
>>>
>>> As I stated before, a point in time defined with the time of 11:30
>>> GMT, whichever date, formats into the same date (textually) in
>>> virtually all timezones. However, I still have some confusion about
>>> this. If I look at a map of the world, virtually all places on the
>>> planet are in the -11 +12 offset range:
>>>
>>> http://www.yeswatch.com/timekeeper/images/manual/time-zone-map-large.jpg
>>>
>>> However, Java provides different results. For example, the "New
>>> Zealand Standard Time" is at +13. Something I do not understand at
>>> all (since geographically it is partly in +11, partly in +12). So,
>>> apparently this method does not cover 100% of the globe. Bummer. I
>>> guess that a custom formatter would be necessary to cover also
>>> those time zones (-12, +13, +14). Or I can just ignore the New
>>> Zealanders :P
>>>
>>> F
>>>
>>> btw, sorry for the confusion, I should have indicated that this is
>>> a JC scenario, and perhaps you could have seen what I was trying to
>>> say.
>>> _______________________________________________
>>> 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
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>>
>>
>>
>> Peter Vandoros
>> Software Engineer
>> Etech Group Pty Ltd
>> Level 3/21 Victoria St
>> Melbourne VIC 3000
>> Australia
>>
>> Ph: +61 3 9639 9677
>> Fax: +61 3 9639 9577
>> ----------------------------------
>> IMPORTANT: This e-mail message and any attachments are confidential
>> and may be privileged. If received in error, please reply to this
>> message and destroy all copies and any attachments. You should check
>> this message and any attachments for viruses or defects. Our
>> liability is limited to resupplying any affected message or
>> attachments. For more information about Etech Group, please visit us
>> at http://www.etechgroup.com.au.
>>
>>
>>
>>
>
> _______________________________________________
> 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
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
Peter Vandoros
Software Engineer
Etech Group Pty Ltd
Level 3/21 Victoria St
Melbourne VIC 3000
Australia
Ph: +61 3 9639 9677
Fax: +61 3 9639 9577
----------------------------------
IMPORTANT: This e-mail message and any attachments are confidential and
may be privileged. If received in error, please reply to this message and
destroy all copies and any attachments. You should check this message and
any attachments for viruses or defects. Our liability is limited to
resupplying any affected message or attachments. For more information
about Etech Group, please visit us at http://www.etechgroup.com.au.
Attachment:
DateTest.java
Description: /
_______________________________________________
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