Looking for parser for Email (MIME)

[Roland Huettmann]

Hello Kay

Thank you for your reply. It can be argued. )))

Well, actually i am using a naming convention using YYYMMDD_HHMM for
myself, but it can not be enforced in a business environment easily and has
other disadvantages.

The problem with modification date/time is that it will be updated when
there is any change, and especially also when in certain other operations
on the file. This modification date/time can be set of course, but then it
would have to be reset too often. And during copy-paste such dates/times
change.

Changing the creation date is "fraudulent"? It depends on how you see it.
These are documents where the user is the owner. The system is not the
"owner" in my humble opinion. Why should someone else (system...?) tell me
what to set as the file creation date which is irrelevant in such case? It
is a matter of semantics. Since there is no "user creation date/time" there
is only this file creation date/time - and in this sense by purpose it is
"misused" for another purpose.

I am also not interested in the date when a sheet of paper was produced. I
am interested in the date which is in the contract signed using such paper.
And even if a copy is made, I am still interested in the original content
date and not the date of the copy of the paper.

The result in my clients small environment: No problems with having to
stick to naming conventions, files are well ordered the way they should be,
people find what they need. In three years we had never a bad result. It is
well respected and accepted.

But I understand of course that it can be argued... ))). And it will not
become a standard. I am aware of this ). So, I agree, it should not be a
recommendation.

Roland





On 25 March 2016 at 01:53, Kay C Lan <lan.kc.macmail at gmail.com> wrote:

> On Thu, Mar 24, 2016 at 6:03 PM, Roland Huettmann
> > I find it VERY convenient since the actual file creation
> > date is not of importance. The content of the file is important. For
> > example, a Word document has a date of the Content (a letter for example,
> > or a contract). Why should this not be reflected in a *persistent* date
> of
> > the file itself?
>
> I don't understand. The detailed files gives you:
>
> creation date & time
> last modified date & time
> last accessed date & time
> last back up date & time
>
> You start writing email and send it today. It's date (forgetting time)
> is the same as the creation and modification date.
>
> You start writing a contract today and finish it tomorrow. It's date
> is the same as it's last modified date.
>
> You can read any of those files multiple times at any later date and
> it doesn't change their creation or last modified dates.
>
> In you go back into the contract and modify it at a later day, then
> the amended contract should be re-dated and it should match the last
> modified date.
>
> To create a document today, and in it's content date it last week (or
> next week) and then use a program to change it's electronic creation
> date to match; or to go into a completed contract a some much later
> date, and modify it and then use a program to electronically back date
> it's modification date all seems fraudulent to me.
>
> If there is some other date that is extremely important to the file
> then surely this would be dealt with using a sensible storing and
> naming convention. i.e. if you were writing someone's biography you
> might  have folders for each year and name the files with a prefix
> mmdd month and day format to sort them chronologically. For contracts,
> after a contract is signed it's scanned so this scanned document could
> be named 'ACME contract signed yyyymmdd'
>
> All relevant dates are then easily accessible via the files creation
> date, modification date and full path name.
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>