Re: Dates in General
Re: Dates in General
- Subject: Re: Dates in General
- From: Paul Scott <email@hidden>
- Date: Thu, 3 Jan 2008 12:01:40 -0800
On Jan 3, 2008, at 6:52 AM, Luther Fuller wrote:
[from Dates] On Jan 3, 2008, at 8:19 AM, Michael wrote:
Yes...you are correct of course....thank you. But, may I ask
another issue that has arisen. If the date sent is in a different
time zone, then Mail ( and I guess the system, presents the time
in local time...which makes sense. ( I assume it uses the settings
as defined by the user). So, if one compares two equivalent times,
but in different time zones, does the OS consider them equal ie
the string might be different, but the object date should be the
same.
Here is what I am now using.
set msgs to every message of (mailbox "INBOX" of account "Foo")
whose (message id is "email@hidden") and (date sent is Date "Wed, 14
Nov 2007 15:12:15 +0100")
Now, I am in Time zone -8, so the time shown on that particular
email is different, but I would have thought that it would still
select it. I have not yet figured out why it is not selecting it,
but it isn't.
Yes, the Date Sent and the Date Received in Mail are local. At least
in Mail, you can look at the raw header to find the actual date and
time zone of a message.
As far as I can tell, creation/modification dates for files in
general have a problem with this, at least on Mac/Unix OS. The
creation/modification dates for a file on Mac/Unix OS are always
local, without a time zone. This, of course, causes a problem if you
need to know the precise date/time for a file. (I've looked-up
details on this, but that was some time ago and I may have forgotten
something.)
Does anyone know more about this? In particular, is there any
proposed standard that would require date/times for a file to be
recorded as UTC, while allowing the displayed date to be local?
None that I've ever found. The problem seems insoluble on close
inspection. A complete analysis of the problem reveals that even
storing the time zone offset along with the date is not enough. I've
spent weeks on this problem with some of the best minds I've ever
worked with. There are subtleties that creep into the picture that
aren't readily apparent. Depending on the application (and the
operating system), it may not matter much. But when perennial accuracy
on heterogeneous systems is paramount, the best compromise we've been
able to come up with -- actually, we borrowed the idea from IBM -- is
to store both UTC and local date, both generated by the same seed on
the local computer (this may need to be done twice!). However, even
this approach isn't perfect.
I haven't taken up a dialogue with any C-runtime authors dealing with
the time functions, but from what I've seen, all runtime libraries are
fraught with problems, Microsoft's being horribly deficient. But they
are good enough for most purposes. The question comes down to this:
how accurate do you need to be?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden
| References: | |
| | >Dates (From: Michael <email@hidden>) |
| | >Re: Dates (From: Michelle Steiner <email@hidden>) |
| | >Re: Dates (From: Michael <email@hidden>) |
| | >Re: Dates (From: Axel Luttgens <email@hidden>) |
| | >Re: Dates (From: Michael <email@hidden>) |
| | >Dates in General (From: Luther Fuller <email@hidden>) |