Why does CGate corrupt all calender entries with dates before 1.1.1971?
I maintain a Brithday Calendar in Thunderbirds Calender. All entries are
dated to the real birthday of the persons with yearly recurrence.
If I store the data of old persons like me on CGate the year of birthday
is converted to 1971. I could not find a restriction in the vcalender
specification that entries before 1971 are invalid.
Is there any chance to get this corrected in the GA relase of 5.4?
Greetings from Austria
Hannes
#############################################################
This message is sent to you because you are subscribed to
the mailing list <CGat...@mail.stalker.com>.
To unsubscribe, E-mail to: <CGateP...@mail.stalker.com>
To switch to the DIGEST mode, E-mail to <CGatePr...@mail.stalker.com>
To switch to the INDEX mode, E-mail to <CGatePr...@mail.stalker.com>
Send administrative queries to <CGatePro...@mail.stalker.com>
maybe one more interested person will speed up solvimg the problem. lets see ... :-)
bw
J
Von meinem iPhone4 gesendet
i think this failure will never be solved. i posted this bug about two years ago. i cannot understand why it is so hard to fix it. there are some hints about UTC and the unix timestamp. i cannot undertsand this situatuin, too. i have not heart anything from technical support. for me its very aggravating, too. we have to administrate our birthdaylists in excel or similar things. it is really unconceivalble.
maybe one more interested person will speed up solvimg the problem. lets see ... :-)
bwJ
Von meinem iPhone4 gesendet
Am 27.03.2011 um 11:36 schrieb Hannes Hromadka <Hrom.061...@aon.at>:
#############################################################This message is sent to y ou because you are subscribed to
the mailing list <CGat...@mail.stalker.com>.To unsubscribe, E-mail to: <CGateP...@mail.stalker.com>To switch to the DIGEST mode, E-mail to <CGatePr...@mail.stalker.com>To switch to the INDEX mode, E-mail to <CGatePr...@mail.stalker.com>Send administrative queries to
---
Best regards
Juergen
--On 28 March 2011 02:39:01 +0200 "Juergen P." <j...@core.at> wrote:
> hello,
>
> quick summary:
>
> cgatepro's calendar is not a birthday calendar or reminder. it is used
> for scheduling.
This is nonsense. There is nothing in any of the vCalendar/iCalendar
specifications that says that you can't use a compliant calendar for
birthday reminders or that would technically prevent you from doing so. For
that matter, there's nothing that says you _must_ use it for "scheduling"
and not as a diary/record of past events or an appointment book - not
everybody uses, or has any need for, groupware! There is also, of course,
nothing in the specifications that says that dates before 1971 are invalid.
As a counterpoint, I just added a all-day event, repeating yearly starting
from March 27, 1942, to my MobileMe calendar (the new CalDAV version that
Apple has been making people migrate to) and it works fine; I can go all
the way back to 1942 on the calendar and see it on March 27 every year from
then until now. I would be willing to bet that Google Calendar also handles
repeating birthday-type events properly even if they start before 1971,
though I haven't tried it yet. Of course, I don't really have to do such
things myself on MobileMe calendar because Apple's software automatically
makes a birthday calendar from the birthdays specified in my address
book... but that's neither here nor there.
It seems to me that if there's a problem with CommuniGate's calendar in
this regard, it's a problem with CommuniGate and not with the standards. If
some lazy programmer wants to make an excuse about it being hard to keep
track of dates before the epoch because of the way UNIX timestamps work,
that's their prerogative; using UNIX timestamps for calendaring is absurd
because they break both in the future and the past. The calendaring specs
certainly don't use UNIX timestamps, and I'd imagine this fragility is part
of the reason why.
-Dan
------------------------------------------------------------------
Daniel M. Zimmerman TFF Enterprises
1900 Commerce St. Box 358426 http://www.tffenterprises.com/
Tacoma, Washington 98402 USA d...@tffenterprises.com
http://en.wikipedia.org/wiki/Unix_time
So, to understand you a little better you are setting a date in the
calander before 1970? My suggestion would be to stop organising it this
way, and just start the schedule when you start the schedule and add the
birth date of the person in the description.
Simply put, for any unix machine there is no time before 1970. This is
not a limitation or a bug in CGate, but how the unix machines of the
world operate.
Thanks
Jurgen
--
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
quick summary:
cgatepro's calendar is not a birthday calendar or reminder. it is usedfor scheduling.
This is nonsense. There is nothing in any of the vCalendar/iCalendar specifications that says that you can't use a compliant calendar for birthday reminders or that would technically prevent you from doing so. For that matter, there's nothing that says you _must_ use it for "scheduling" and not as a diary/record of past events or an appointment book - not everybody uses, or has any need for, groupware! There is also, of course, nothing in the specifications that says that dates before 1971 are invalid.
As a counterpoint, I just added a all-day event, repeating yearly starting from March 27, 1942, to my MobileMe calendar (the new CalDAV version that Apple has been making people migrate to) and it works fine; I can go all the way back to 1942 on the calendar and see it on March 27 every ye ar from then until now. I would be willing to bet that Google Calendar also handles repeating birthday-type events properly even if they start before 1971, though I haven't tried it yet. Of course, I don't really have to do such things myself on MobileMe calendar because Apple's software automatically makes a birthday calendar from the birthdays specified in my address book... but that's neither here nor there.
It seems to me that if there's a problem with CommuniGate's calendar in this regard, it's a problem with CommuniGate and not with the standards. If some lazy programmer wants to make an excuse about it being hard to keep track of dates before the epoch because of the way UNIX timestamps work, that's their prerogative; using UNIX timestamps for calendaring is absurd because they break both in the future and the past. The calendaring specs certainly don't use UNIX timestamps, and I'd imagine this fragility is part of the reason why.
-Dan
------------------------------------------------------------------Daniel M. Zimmerman TFF Enterprises1900 Commerce St. Box 358426Tacoma, Washington 98402 USA
From: Juergen P. [mailto:j...@core.at]
To: CommuniGate Pro Discussions [mailto:CGat...@mail.stalker.com]
Sent: Mon, 28 Mar 2011 12:40:02 +0200
Subject: Re: Calendar and dates before 1.1.1971
On Sun, 27 Mar 2011 19:09:36 -0700"Daniel M. Zimmerman" <dmz-...@tffenterprises.com> wrote:--On 28 March 2011 02:39:01 +0200 "Juergen P." <j...@core.at> wrote:hello,quick summary:cgatepro's calendar is not a birthday calendar or reminder. it is usedfor scheduling.This is nonsense. There is nothing in any of the vCalendar/iCalendar specifications that says that you can't use a compliant calendar for birthday reminders or that would technically prevent you from doing so. For that matter, there's nothing that says you _must_ use it for "scheduling" and not as a diary/record of past events or an appointment book - not everybody uses, or has any need for, groupware! There is also, of course, nothing in the specifications that says that dates before 1971 are invalid.my nonsense:we have 2011, now, i think -
why do you want to enter dates 1942 for example? the only effect you'll have is having created many r epeated events in the calendar folder.
that is nonsense :-)don't you need disk-space for other things?i understood that communigate pro is an application server - if you need appplications you can write it by yourself-but anyway - you said it by yourself - you CAN use it as a birthday calendar :-)you CAN use it also to turn on/off the light via dialing an defined extension which starts a script if a call is received .
i said bithday reminders like counting repetitions from the first event till now and showing then: "th is is the 41st repetition of my birthday" are not included. the message would then be: juergen is 41 today - i hope this is clear now :-)
i f you need something like that you can create yourself a script and run it once a day to schedule this.you can edit this years calendar, put ther all birthdays (additional info could be the real birthday) and set it to repeat - quick and dirty solution for your problem.greetings,juergen
As a counterpoint, I just added a all-day event, repeating yearly starting from March 27, 1942, to my MobileMe calendar (the new CalDAV version that Apple has been making people migrat e to) and it works fine; I can go all the way back to 1942 on the calendar and see it on March 27 every year from then until now. I would be willing to bet that Google Calendar also handles repeating birthday-type events properly even if they start before 1971, though I haven't tried it yet. Of course, I don't really have to do such things myself on MobileMe calendar because Apple's software automatically makes a birthday calendar from the birthdays specified in my address book... but that's neither here nor there.
It seems to me that if there's a problem with CommuniGate's calendar in this regard, it's a problem with CommuniGate and not with the standards. If some lazy programmer wants to make an excuse about it being hard to keep track of dates before the epoch because of the way UNIX timestamps work, that's their prerogative; using UNIX timestamps for calendaring is absurd because they break both in the future and the past. The calendaring specs certainly don't use UNIX timestamps, and I'd imagine this fragility is part of the reason why.-Dan
------------------------------------------------------------------Daniel M. Zimmerman TFF Enterprises1900 Commerce St. Box 358426Tacoma, Washington 98402 USA
#############################################################This message is sent to you because you are subscribed tothe mailing list <CGat...@mail.stalker.com>.To unsubscribe, E-mail to: <CGateP...@mail.stalker.com>
< i> To switch to the DIGEST mode, E-mail to <CGatePr...@mail.stalker.com>
To switch to the INDEX mode, E-mail to <CGatePr...@mail.stalker.com>Send administrative queries to
---Best regardsJuergen
On 28.03.2011 02:39, Juergen P. wrote:
> cgatepro's calendar is not a birthday calendar or reminder. it is used
> for scheduling.
A birthday is an event which is repeated every year, nothing more.
> if you'll need a birthday-reminder, you could write yourself a script
> which handles that.
> some application what creates an ical-event.
> this script could be executed once a day, scans some database and
> calculates the actual age.
> (data could be stored as ldap data for example)
Why should I waste disk space and flood my server with hundred duplicate
entries?
A recurring event is stored only once in the server.
On 28.03.2011 12:40, Juergen P. wrote:
> my nonsense:
> we have 2011, now, i think -
> why do you want to enter dates 1942 for example? the only effect you'll
> have is having created many repeated events in the calendar folder.
> that is nonsense :-)
>
> don't you need disk-space for other things?
Please check how repeated events are stored in iCal.
Maybe you have old applications like the "event list" application I have
on my Palm V. Such old applications indeed create multiple entries in
the calender wasting storage space.
When I store a historical event which is repeated regulary in my
calendar I do not like to have to have a note added to the event to know
when the first occurence was 8-(
Thunderbird/lightning does it right when storing caledendars locally,
there are also no problems whith historical events in MS-Outlook.
Only CGate has this annoying bug.
Hannes
Hello:
> So, to understand you a little better you are setting a date in the
> calander before 1970? My suggestion would be to stop organising it this
> way, and just start the schedule when you start the schedule and add the
> birth date of the person in the description.
> Simply put, for any unix machine there is no time before 1970. This is
> not a limitation or a bug in CGate, but how the unix machines of the
> world operate.
A date is a date and a unix time stamp is a unix time stamp. iCalender
RFC does not mention unix time stamps when it covers handling dates.
For a programmer unix time stimp makes it very easy to calculate with
date and time differences.
But the easy solution is not allways the best solution it may have
drawbacks. This drawback of the soultiuon used in CGate forces me to
look for another solution. I'm trying CALiDav next. Cross fingers that I
do not have to use Exchange server 8-(
(I know that in Exchange Server my birthday list is stored correct)
Hello:
> RFC 3283 Guide to Internet Calendaring June 2002
This RFC is old, actual RFC for iCalender is RFC 5545 (former RFC 2445)
(iCalendar-Standard)
The fields in question are
RRULE:FREQ=YEARLY
DTSTART;VALUE=DATE:19620311
DTEND;VALUE=DATE:19620312
Spedification for DATE which is used for DTSTART and DTEND in RFC 5545:
3.3.4. Date
Value Name: DATE
Purpose: This value type is used to identify values that contain a
calendar date.
Format Definition: This value type is defined by the following
notation:
date = date-value
date-value = date-fullyear date-month date-mday
date-fullyear = 4DIGIT
date-month = 2DIGIT ;01-12
date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31
;based on month/year
Description: If the property permits, multiple "date" values are
specified as a COMMA-separated list of values. The format for the
value type is based on the [ISO.8601.2004] complete
representation, basic format for a calendar date. The textual
format specifies a four-digit year, two-digit month, and two-digit
day of the month. There are no separator characters between the
year, month, and day component text.
No additional content value encoding (i.e., BACKSLASH character
encoding, see Section 3.3.11) is defined for this value type.
Example: The following represents July 14, 1997:
19970714
There is no indication that this is valid only for dates after 1.1.1971.
Therefore my above sample birthday is a valid entry for iCalender,
similar as other examples with dates before unix timestamp reference
1.1.1970 as used in the RFC
In 3.6.5. Time Zone Component
......
Example: The following are examples of the "VTIMEZONE" calendar
component:
This is an example showing all the time zone rules for New York
City since April 30, 1967 at 03:00:00 EDT.
BEGIN:VTIMEZONE
TZID:America/New_York
LAST-MODIFIED:20050809T050000Z
BEGIN:DAYLIGHT
DTSTART:19670430T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19730429T070000Z
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
BEGIN:STANDARD
Try to store this in CGate.
Ciao,
Hello:
> drawbacks. This drawback of the soultiuon used in CGate forces me to
> look for another solution. I'm trying CALiDav next.
DAViCal looks good after some quick tests.
This is what Lightning stores
BEGIN:VEVENT
CREATED:20110328T194305Z
LAST-MODIFIED:20110328T194414Z
DTSTAMP:20110328T194414Z
UID:4fab483b-b412-4913-8c8c-720b91bc3074
SUMMARY:Test Geburtstag
RRULE:FREQ=YEARLY
DTSTART;VALUE=DATE:19620329
DTEND;VALUE=DATE:19620330
DESCRIPTION:test 1962
TRANSP:TRANSPARENT
SEQUENCE:2
X-MOZ-GENERATION:2
END:VEVENT
@Communigate support: Please correct the bug in CGate
There are many limitations that you live with in the computing world,
32bit OS < 4gb of RAM, for an example. You lived with that for years,
was that also a bug? Who is going to fix your 32x OS < 4gb of RAM bug?
You could use PAE I suppose.
Good luck.
On 29/03/11 6:57 AM, Hannes Hromadka wrote:
> @Communigate support: Please correct the bug in CGate
--
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
#############################################################
On 28.03.2011 20:33, Hannes Hromadka wrote:
Hello:
drawbacks. This drawback of the soultiuon used in CGate forces me tolook for another solution. I'm trying CALiDav next.
DAViCal looks good after some quick tests.
This is what Lightning stores
BEGIN:VEVENT
@Communigate support: Please correct the bug in CGate
Hannes
#############################################################This message is sent to you because you are subscribed tothe mailing list <CGat...@mail.stalker.com>.To unsubscribe, E-mail to: <CGateP...@mail.stalker.com>To switch to the DIGEST mode, E-mail to <CGatePr...@mail.stalker.com>To switch to the INDEX mode, E-mail to <CGatePr...@mail.stalker.com>Send administrative queries to
This is accurate, but it misses the point. Yes, it's a limitation, not a
bug. However, it is a limitation that causes unexpected and undesirable
behavior from the point of view of most users. Users (and many client
programs) use the actual birth year in the event because it is simpler
and more elegant than any other proposed solution. By looking at the
start date, you can determine in exactly what year the person was born.
If some other value is used (1971 or the year the event was created),
the only thing you know by looking at the information is that it MIGHT
be accurate. It might not.
Moreover, it is a limitation that few, if any, competitors to CGP share.
THis means that is APPEARS to be a bug from the point of view of most
users, including the management types who approve the purchase of CGP or
its replacement, and they almost certainly have no idea what a unix
time-stamp is.
Further, the unix time-stamp is an explanation, not a valid excuse. It
explains why this is so, but it does not make it acceptable. To use your
32-bit OS analogy, if all of your competitors are also 32-bit and they
all share the limitation, then it's a valid excuse. If you are the only
remaining 32-bit OS and none of your competitors share that limitation,
it's no-longer valid because there is a proven way to work around the
limitation. More importantly, it means that that limitation makes your
product look bad when compared to your competitors.
If anyone thinks that the average corporate president of a CGP customer
wouldn't use the birth-year as the start date when entering a birthday,
think again. If anyone thinks that President won't be annoyed when he
realizes that he has no idea when "Big Customer's CEO's Daughter" was
born because CGP decided 1971 was better than the year he entered, think
again. If anyone thinks that President won't have something against CGP
when it comes time to renew the contract or consider switching to
another product, think again. This is true for ISP customers, too, as
the person in question will be the president of one of your customers.
OK, my $0.02,
Tom
PS: The part of this behavior that actually IS a BUG is that the system
changes the date that the user specified without notifying or asking the
user's permission. I understand that there is a limitation, and I
understand that CGS might choose not to fix it. It is, however, UTTERLY
UNACCEPTABLE that a piece of software will change a piece of data input
by a user without notifying that user in some way. "Error: Dates before
1971 are not supported" or "Notice: The start year for this event has
been moved from 1969 to 1971 due to limitations in the calendar program"
is the minimum acceptable.
Before anyone claims that CGS has no way of doing this because they
don't know what client you are using, I submit that CGP sends me an
e-mail when an event is approaching, so they can at least send an e-mail.
This limitation has not bothered me yet, but as stated in this email,
the current setup appears to be unacceptable.
Hello Tom:
> On 03/28/2011 5:48 PM, Support@ish wrote:
>> They probably do not consider it a bug, so I doubt they will. Just like
>> I do not consider it a bug. Just a limitation.
>>
>> There are many limitations that you live with in the computing world,
>> 32bit OS < 4gb of RAM, for an example. You lived with that for years,
>> was that also a bug? Who is going to fix your 32x OS < 4gb of RAM bug?
>> You could use PAE I suppose.
>>
>> Good luck.
>
> This is accurate, but it misses the point. Yes, it's a limitation, not a
> bug. However, it is a limitation that causes unexpected and undesirable
> behavior from the point of view of most users. Users (and many client
> programs) use the actual birth year in the event because it is simpler
> and more elegant than any other proposed solution. By looking at the
> start date, you can determine in exactly what year the person was born.
Thanks for the summary and all the other arguments.
This limitation (or bug when testing against RFC) makes CPG unusable for
my usage of calendering.
That's a pitty because CGate fits very perfect to other needs I have in
a UCS.
My workaround will be to store historical events in a DAViCal running on
the same machine besides CGate.
Hannes
> what's the reason for not creating repeated events in the year you are
> living?
See Toms post from 16:20. There is nothing to add.
Thanks for the compliment, Hannes.
Juergen: The reason for not creating repeated events in the current year
is that it is not as simple, elegant, useful, or intuitive as using the
person's birth year.
In other words, you *could* do it, but the only reason anyone *would* do
it is as a workaround for the limitation in the software. Remove the
limitation and it would make no sense to do it that way.
Tom
On 29.03.2011 03:55, Juergen P. wrote:
what's the reason for not creating repeated events in the year you areliving?
See Toms post from 16:20. There is nothing to add.
Hannes
#############################################################This message is sent to you because you are subscribed tothe mailing list <CGat...@mail.stalker.com>.To unsubscribe, E-mail to: <CGateP...@mail.stalker.com>To switch to the DIGEST mode, E-mail to <CGatePr...@mail.stalker.com>To switch to the INDEX mode, E-mail to <CGatePr...@mail.stalker.com>Send administrative queries to
I think people have missed the big picture in this issue. The Calendar is
marketed as something to hold FUTURE events and give reminders. It does that
very well. If you want a reminder of someone's birthday, put in the birthday
for 2011 and an annual reminder. If you need to figure out someone's age,
add their birth year in the message section of the calendar entry. Problem
solved!
Guide/WebCalendar.html
"The CommuniGate Pro WebUser Interface allows you to manage your Calendar
information (meetings, appointments, events, etc.)."
Nowhere does the Guide say anything about managing historic or past events.
Please don't bother telling me it fails to mention any sort of limitation in
that statement, because the examples do not suggest this. If you are giving
up an excellent product because it won't let you put in the date of birth
for someone over 40 years old, well, to each his/her own.
matthew black
e-mail postmaster
california state university, long beach
> Nowhere does the Guide say anything about managing historic or past
> events. Please don't bother telling me it fails to mention any sort of
> limitation in that statement, because the examples do not suggest this.
> If you are giving up an excellent product because it won't let you put in
> the date of birth for someone over 40 years old, well, to each his/her
> own.
The guide doesn't say anything about the calendar retaining calendar events
after they have occurred (and have thus become "historic or past events")
either, but I imagine most users would be quite annoyed if they opened
their calendars to discover that all events prior to "right now" had just
disappeared.
Exchange works fine with dates before 1971.
Google Calendar works fine with dates before 1971.
iCal/MobileMe (both the old system and the new system) works fine with
dates before 1971.
CommuniGate Pro does not seem like an "excellent product" for calendaring
compared to those, at least for the purposes the particular user who
started the discussion has in mind (note that I'm not disputing its
excellence in other areas, such as serving email). If the excuse for this
problem turns out to be that UNIX timestamps are being used, that's
essentially the same as "the implementers were lazy". Even if you make the
assumption that users don't want to track events before 1970 (how did we
end up with 1971, anyway? the UNIX epoch starts in 1970), or after early
2038 when the counter rolls over, you're still storing events that can only
be accurate to the second (actually the minute for most people's calendars,
but the format in CalDAV supports seconds) with millisecond precision. UNIX
timestamps are just not designed for this application.
Moreover, it doesn't matter (in terms of determining whether the
functionality is reasonable as is) _why_ the user wants to put a date
before 1971 in their calendar. If a limitation of the server prevents him
from doing so, that's fine... but the server should say so, explicitly,
when the user attempts to exceed the limitation rather than corrupting the
user's data after they enter it. If a user enters a date into a calendar,
and the calendar changes the date without warning, that's data corruption
and obviously bad behavior.
-Dan
------------------------------------------------------------------
Daniel M. Zimmerman TFF Enterprises
1900 Commerce St. Box 358426 http://www.tffenterprises.com/~dmz/
Tacoma, WA 98402 USA d...@tffenterprises.com
On 29.03.2011 03:55, Juergen P. wrote:
what's the reason for not creating repeated events in the year you areliving?
See Toms post from 16:20. There is nothing to add.
Hannes
#############################################################This message is sent to you because you are subscribed tothe mailing list <CGat...@mail.stalker.com>.To unsubscribe, E-mail to: <CGateP...@mail.stalker.com>To switch to the DIGEST mode, E-mail to <CGatePr...@mail.stalker.com>To switch to the INDEX mode, E-mail to <CGatePr...@mail.stalker.com>Send administrative queries to
> Intuition does not mean the same thing to all people. My intuition says to put an annual event for the current year and make it recurring. I certainly don't go to someone's birth year in my Lotus Notes account and don't know anyone at my work who would either.
Matthew,
You make a valid point, but:
1.) I think you will find that various contact/calendar clients can be configured to automatically add recurring events for birthdays, and they use the birth year as the start date.
2.) Folks like me use the birth year when manually creating events.
3.) It is absurd that the server modifies the user's data without notifying the user.
Thankfully, it appears that a fix is in the works, so we can both be happy!
Tom
Hello:
> "The CommuniGate Pro WebUser Interface allows you to manage your
> Calendar information (meetings, appointments, events, etc.)."
>
> Nowhere does the Guide say anything about managing historic or past
> events. Please don't bother telling me it fails to mention any sort of
> limitation in that statement, because the examples do not suggest this.
Webinterface and Pronto in 5.4c2 have changed behaviour compared to
older versions.
Both have no longer the possibility to enter dates directly, only via a
date chooser application.
In Webinterface I can roll back before 71, but if I choose 67 and store
an event. The event is gone after pressing save.
I did not check if the event is stored as 2067 then.
Pronto does it better. It does not allow to roll back to years before 71.
> If you are giving up an excellent product because it won't let you put
> in the date of birth for someone over 40 years old, well, to each
> his/her own.
Not till I find another product which can replace CGate. (noting in
sight when it comes to PBX SIP features)
But I need to find a workaround. Got it, installed DAViCal besides CGate
and store Anniversaries in a second calendar.
Hannes
Hello:
> hier die information vom CGS dev-team.
>
> Zitat.
>
> "we are aware of the problem. During the 5.3 and 5.4 development cycle
> we were changing all timestamps variables at objects that can be later
> changed to support 64-bit timestamps and thus the dates earlier than
> 'unix epoch' "
>
> /Zitat
This sounds promising, hope that the solution will be available on 32
bit OS too.
Von meinem iPhone4 gesendet