Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Calendar and dates before 1.1.1971

19 views
Skip to first unread message

Hannes Hromadka

unread,
Mar 27, 2011, 5:36:28 AM3/27/11
to
Hello:

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>

Joachim Stampfer

unread,
Mar 27, 2011, 3:13:39 PM3/27/11
to
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 ... :-)

bw
J

Von meinem iPhone4 gesendet

Juergen P.

unread,
Mar 27, 2011, 8:25:29 PM3/27/11
to
hello,

here you'll find the answer:


RFC 3283             Guide to Internet Calendaring             June 2002


5.1 Scheduling People, not Calendars

  Meetings are scheduled with people; however, people may have many
  calendars, and may store these calendars in many places.  There may
  also be many routes to contact them.  The calendaring protocols do
  not attempt to provide unique access for contacting a given person.
  Instead, 'calendar addresses' are booked, which may be e-mail
  addresses or individual calendars.  It is up to the users themselves
  to orchestrate mechanisms to ensure that the bookings go to the right
  place.

5.2 Administration

  The calendaring protocols do not address the issues of administering
  users and calendars on a calendar service.  This must be handled by
  proprietary mechanisms for each implementation.


kr

Juergen





On Sun, 27 Mar 2011 21:13:39 +0200
Joachim Stampfer <joachim....@gmail.com> wrote:
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 ... :-)

bw
J

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

Juergen P.

unread,
Mar 27, 2011, 8:39:01 PM3/27/11
to
hello,

quick summary:

cgatepro's calendar is not a birthday calendar or reminder. it is used for scheduling.
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)

kind regards

Juergen
---

Best regards

Juergen

---

Best regards

Juergen

Daniel M. Zimmerman

unread,
Mar 27, 2011, 10:09:36 PM3/27/11
to

--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

Support@ish

unread,
Mar 27, 2011, 11:18:37 PM3/27/11
to
I could hazard a couple of guesses, but it will be something to do with:

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

Juergen P.

unread,
Mar 28, 2011, 6:40:02 AM3/28/11
to

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 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.

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?

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: "this 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 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 Enterprises
1900 Commerce St. Box 358426
Tacoma, Washington  98402  USA
            dmz@tffente rprises.com

Maik Heinrich

unread,
Mar 28, 2011, 7:52:22 AM3/28/11
to
Hello

when you add the birthday entry to an Person/Contact this bug also make every Person which is born before 1971 to born in 1971. This is definitiv a BUG in Communigate.

Greetings Maik

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 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.

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 Enterprises
1900 Commerce St. Box 358426
Tacoma, Washington  98402  USA
            d...@tffenterprises.com

#############################################################
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>
< 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 regards

Juergen

Hannes Hromadka

unread,
Mar 28, 2011, 2:25:47 PM3/28/11
to
Hello:


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

Hannes Hromadka

unread,
Mar 28, 2011, 2:33:13 PM3/28/11
to
On 28.03.2011 05:18, Support@ish wrote:

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)

Hannes Hromadka

unread,
Mar 28, 2011, 2:12:30 PM3/28/11
to
On 28.03.2011 02:25, Juergen P. wrote:

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,

Hannes Hromadka

unread,
Mar 28, 2011, 3:57:29 PM3/28/11
to
On 28.03.2011 20:33, Hannes Hromadka wrote:

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

Support@ish

unread,
Mar 28, 2011, 5:48:12 PM3/28/11
to
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.

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

#############################################################

Juergen P.

unread,
Mar 28, 2011, 9:55:57 PM3/28/11
to
hello hannes,

what's the reason for not creating repeated events in the year you are living?
da birthday is not affected by that, it's every year at the same date. are your applications doing something special with those dates ?
i mean create superspecial events on round birthdays?  could you please explain exactly what your problem is, redgardless communigate pro has a bug or not  - because many of us don't see a problem with that in general. also would be nice to get info about software used, where you enter those date and what you expect to happen in that application. maybe you could send us a link  to a video  - so we can watch for better understanding.


tx
kr

Juergen


On Mon, 28 Mar 2011 21:57:29 +0200
Hannes Hromadka <Hrom.061...@aon.at> wrote:
On 28.03.2011 20:33, Hannes Hromadka wrote:

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


    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

---

Best regards

Juergen

Tom Rymes

unread,
Mar 29, 2011, 10:20:05 AM3/29/11
to
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.
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.

Jeff Wark

unread,
Mar 29, 2011, 10:51:53 AM3/29/11
to
Can I upvote this for being so well put?

This limitation has not bothered me yet, but as stated in this email,
the current setup appears to be unacceptable.

Hannes Hromadka

unread,
Mar 29, 2011, 1:28:31 PM3/29/11
to
On 29.03.2011 16:20, Tom Rymes wrote:

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

Hannes Hromadka

unread,
Mar 29, 2011, 2:50:03 PM3/29/11
to
On 29.03.2011 03:55, Juergen P. wrote:

> 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.

Tom Rymes

unread,
Mar 29, 2011, 5:12:09 PM3/29/11
to
On 03/29/2011 2:50 PM, Hannes Hromadka wrote:
> On 29.03.2011 03:55, Juergen P. wrote:
>
>> 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

Juergen P.

unread,
Mar 29, 2011, 9:48:16 PM3/29/11
to
hi hannes,

i see, thanx.

kr

Juergen




On Tue, 29 Mar 2011 20:50:03 +0200
Hannes Hromadka <Hrom.061...@aon.at> wrote:
On 29.03.2011 03:55, Juergen P. wrote:

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.

    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

---

Best regards

Juergen

Matthew Black

unread,
Mar 30, 2011, 1:49:11 AM3/30/11
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.

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

Daniel M. Zimmerman

unread,
Mar 30, 2011, 5:06:10 AM3/30/11
to
--On 29 March 2011 22:49:11 -0700 Matthew Black <bl...@csulb.edu> wrote:

> 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

Juergen P.

unread,
Mar 30, 2011, 5:26:47 AM3/30/11
to

FYI

thx..

Juergen



rfc 4791

5.2.6. CALDAV:min-date-time Property


  Name:  min-date-time

  Namespace:  urn:ietf:params:xml:ns:caldav

  Purpose:  Provides a DATE-TIME value indicating the earliest date and
     time (in UTC) that the server is willing to accept for any DATE or
     DATE-TIME value in a calendar object resource stored in a calendar
     collection.

  Conformance:  This property MAY be defined on any calendar
     collection.  If defined, it MUST be protected and SHOULD NOT be
     returned by a PROPFIND DAV:allprop request (as defined in Section
     12.14.1 of [RFC2518]).

  Description:  The CALDAV:min-date-time is used to specify an
     iCalendar DATE-TIME value in UTC that indicates the earliest
     inclusive date that the server is willing to accept for any
     explicit DATE or DATE-TIME value in a calendar object resource
     stored in a calendar collection.  Any attempt to store a calendar
     object resource using a DATE or DATE-TIME value earlier than this
     value MUST result in an error, with the CALDAV:min-date-time
     precondition (Section 5.3.2.1) being violated.  Note that servers
     MUST accept recurring components that specify instances beyond
     this limit, provided none of those instances have been overridden.
     In that case, the server MAY simply ignore those instances outside
     of the acceptable range when p rocessing reports on the calendar
     object resource.  In the absence of this property, the client can
     assume any valid iCalendar date may be used at least up to the
     CALDAV:max-date-time value, if that is defined.

  Definition:

        <!ELEMENT min-date-time (#PCDATA)>
        PCDATA value: an iCalendar format DATE-TIME value in UTC

  Example:

        <C:min-date-time
        >19000101T000000Z</C:min-date-time>




---

Best regards

Juergen

Juergen P.

unread,
Mar 30, 2011, 8:08:05 AM3/30/11
to
hallo,

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

lg

Juergen






On Tue, 29 Mar 2011 20:50:03 +0200
Hannes Hromadka <Hrom.061...@aon.at> wrote:
On 29.03.2011 03:55, Juergen P. wrote:

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.

    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

---

Best regards

Juergen

Tom Rymes

unread,
Mar 30, 2011, 9:30:55 AM3/30/11
to
On Mar 30, 2011, at 1:49 AM, "Matthew Black" <bl...@csulb.edu> wrote:

> 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

Hannes Hromadka

unread,
Mar 30, 2011, 1:20:39 PM3/30/11
to
On 30.03.2011 07:49, Matthew Black wrote:

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

Hannes Hromadka

unread,
Mar 30, 2011, 1:22:11 PM3/30/11
to
On 30.03.2011 14:08, Juergen P. wrote:

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.

Joachim Stampfer

unread,
Apr 4, 2011, 4:22:32 PM4/4/11
to
i hope, the development team can fix this incorrect behavior in 5.4. i hope the problem with new timestamps will not lead to more, i mean more essential, problems. it would be nice. when communigate will fix the problem i have posted for about two years.

Von meinem iPhone4 gesendet

0 new messages