Windows Port Date/Time issue

I am seeing a weird issue with tickets. It appears that it is putting in a
very off date for Closed: and Started: for tickets just created. Evidence:

Created:

Wed. Oct. 22 16:36:58 2003

Starts:

Not set

Started:

Wed. Dec. 31 20:00:00 1969

Last Contact:

Not set

Due:

Not set

Closed:

Wed. Dec. 31 20:00:00 1969

Updated:

http://rtracker:8284/Ticket/Display.html?id=38#lasttrans#lasttrans Wed.
Oct. 22 18:10:05 2003 by tniedens

Any ideas on this one?

Thanks,

Travis

“Niedens, Travis” Travis_Niedens@redlands.edu writes:

very off date for Closed: and Started: for tickets just created.
[…] Wed. Dec. 31 20:00:00 1969

As every self-respecting geek knows, the clocks on a lot of systems
count seconds from that date. Seeing such a date means something is
zero (i.e. no time passed since this famous `epoch’, perhaps shifted
by your time zone). So in other words your newly created ticked has
not been Started, and has not been Closed, which makes sense. It’s
just not saying it very well.

gdm

*** Source: Jargon File (4.3.0, 30 APR 2001) ***
epoch n. [Unix: prob. from astronomical timekeeping] The time and date
corresponding to 0 in an operating system’s clock and timestamp values.
Under most Unix versions the epoch is 00:00:00 GMT, January 1, 1970;
under VMS, it’s 00:00:00 of November 17, 1858 (base date of the U.S.
Naval Observatory’s ephemerides); on a Macintosh, it’s the midnight
beginning January 1 1904. System time is measured in seconds or {tick}s
past the epoch. Weird problems may ensue when the clock wraps around
(see {wrap around}), which is not necessarily a rare event; on systems
counting 10 ticks per second, a signed 32-bit count of ticks is good
only for 6.8 years. The 1-tick-per-second clock of Unix is good only
until January 18, 2038, assuming at least some software continues to
consider it signed and that word lengths don’t increase by then. See
also {wall time}. Microsoft Windows, on the other hand, has an epoch
problem every 49.7 days - but this is seldom noticed as Windows is
almost incapable of staying up continuously for that long.

I didn’t think this was a matter of self-respecting but rather coding. This
is the first ticket tracking system that I have seen this feature on.
Getting 4 people asking me about it in one day without any documentation
stating that this is how a “non-started” ticket handles start/closed dates
isn’t exactly something that leads to self-respect :slight_smile:

TravisFrom: Giles Malet - IST [mailto:gdmalet@ist.uwaterloo.ca]
Sent: Thursday, October 23, 2003 10:36 AM
To: Niedens, Travis
Cc: rt-users@lists.fsck.com
Subject: Re: [rt-users] Windows Port Date/Time issue

“Niedens, Travis” Travis_Niedens@redlands.edu writes:

very off date for Closed: and Started: for tickets just created.
[…] Wed. Dec. 31 20:00:00 1969

As every self-respecting geek knows, the clocks on a lot of systems
count seconds from that date. Seeing such a date means something is
zero (i.e. no time passed since this famous `epoch’, perhaps shifted
by your time zone). So in other words your newly created ticked has
not been Started, and has not been Closed, which makes sense. It’s
just not saying it very well.

gdm

*** Source: Jargon File (4.3.0, 30 APR 2001) ***
epoch n. [Unix: prob. from astronomical timekeeping] The time and date
corresponding to 0 in an operating system’s clock and timestamp values.
Under most Unix versions the epoch is 00:00:00 GMT, January 1, 1970;
under VMS, it’s 00:00:00 of November 17, 1858 (base date of the U.S.
Naval Observatory’s ephemerides); on a Macintosh, it’s the midnight
beginning January 1 1904. System time is measured in seconds or {tick}s
past the epoch. Weird problems may ensue when the clock wraps around
(see {wrap around}), which is not necessarily a rare event; on systems
counting 10 ticks per second, a signed 32-bit count of ticks is good
only for 6.8 years. The 1-tick-per-second clock of Unix is good only
until January 18, 2038, assuming at least some software continues to
consider it signed and that word lengths don’t increase by then. See
also {wall time}. Microsoft Windows, on the other hand, has an epoch
problem every 49.7 days - but this is seldom noticed as Windows is
almost incapable of staying up continuously for that long.

I didn’t think this was a matter of self-respecting but rather coding. This
is the first ticket tracking system that I have seen this feature on.
Getting 4 people asking me about it in one day without any documentation
stating that this is how a “non-started” ticket handles start/closed dates
isn’t exactly something that leads to self-respect :slight_smile:

Well, it does sound like a bug in how RT interacts with windows internal
date/time stuff. On the unix side, these show up as “not set”.