Windows "date modified" and daylight savings time

Discussion in 'Digital Photography' started by bucky3, Nov 2, 2009.

  1. bucky3

    bucky3 Guest

    I just realized that now all my files' "Date Modified" are 1 hr off
    after daylight savings time. This is obvious when you compare the Date
    Modified vs EXIF date picture taken.

    After some research, I learned that the Date Modified timestamp is
    recorded in UTC. Then it is displayed with the current timezone
    adjustment. So before DST, if I had a file modified at 14:00 UTC, and
    my timezone was PDT(-7), then Windows file explorer would display the
    time stamp as 7:00, which was correct. But now that it is DST, which
    is PST(-8), Windows is displaying the time stamp as 6:00, which is
    incorrect.

    Is there a way to have Windows XP display the correct time stamp? I
    think it should take into account the date of the timestamp and figure
    out whether it was during DST or not. So a timestamp of 6/1/2009 14:00
    would be adjusted -7:00 to 7:00 (since 6/1/2009 was during DST).
    Whereas a timestamp of 1/1/2009 14:00 would be adjusted -8:00 to 6:00
    (since 1/1/2009 was not DST).
    bucky3, Nov 2, 2009
    #1
    1. Advertising

  2. bucky3

    bucky3 Guest

    On Nov 2, 9:21 am, bucky3 <> wrote:
    > So before DST, if I had a file modified at 14:00 UTC, and
    > my timezone was PDT(-7), then Windows file explorer would display the
    > time stamp as 7:00, which was correct. But now that it is DST, which
    > is PST(-8), Windows is displaying the time stamp as 6:00, which is
    > incorrect.


    Correction:

    So *DURING* DST, if I had a file modified at 14:00 UTC, and
    my timezone was PDT(-7), then Windows file explorer would display the
    time stamp as 7:00, which was correct. But now that it is *NO LONGER*
    DST, which
    is PST(-8), Windows is displaying the time stamp as 6:00, which is
    incorrect.
    bucky3, Nov 2, 2009
    #2
    1. Advertising

  3. "bucky3" <> wrote in message
    news:...
    > On Nov 2, 9:21 am, bucky3 <> wrote:
    >> So before DST, if I had a file modified at 14:00 UTC, and
    >> my timezone was PDT(-7), then Windows file explorer would display the
    >> time stamp as 7:00, which was correct. But now that it is DST, which
    >> is PST(-8), Windows is displaying the time stamp as 6:00, which is
    >> incorrect.

    >
    > Correction:
    >
    > So *DURING* DST, if I had a file modified at 14:00 UTC, and
    > my timezone was PDT(-7), then Windows file explorer would display the
    > time stamp as 7:00, which was correct. But now that it is *NO LONGER*
    > DST, which
    > is PST(-8), Windows is displaying the time stamp as 6:00, which is
    > incorrect.


    Why is it incorrect? The file was modified at a fixed time, to which is
    either added or not an hour. 06:00 normal time => 07:00 summer time.
    14:00 - 8 hours => 06:00.

    If you always want "wall-clock" time displayed for files, store then on a
    FAT-16 file system. Possibly even a FAT-32 volume, but I haven't checked
    that.

    Cheers,
    David
    David J Taylor, Nov 2, 2009
    #3
  4. bucky3

    Ofnuts Guest

    David J Taylor wrote:
    >
    > "bucky3" <> wrote in message
    > news:...
    >> On Nov 2, 9:21 am, bucky3 <> wrote:
    >>> So before DST, if I had a file modified at 14:00 UTC, and
    >>> my timezone was PDT(-7), then Windows file explorer would display the
    >>> time stamp as 7:00, which was correct. But now that it is DST, which
    >>> is PST(-8), Windows is displaying the time stamp as 6:00, which is
    >>> incorrect.

    >>
    >> Correction:
    >>
    >> So *DURING* DST, if I had a file modified at 14:00 UTC, and
    >> my timezone was PDT(-7), then Windows file explorer would display the
    >> time stamp as 7:00, which was correct. But now that it is *NO LONGER*
    >> DST, which
    >> is PST(-8), Windows is displaying the time stamp as 6:00, which is
    >> incorrect.

    >
    > Why is it incorrect? The file was modified at a fixed time, to which is
    > either added or not an hour. 06:00 normal time => 07:00 summer time.
    > 14:00 - 8 hours => 06:00.


    You're both wrong :) When going DST, you don't change timezones. You
    stay in the same timezone, but apply DST.

    In this time zone, June 21st, 12:00 is the way to denote a specific
    moment in time(*), and there is only one way to denote a specific moment
    in that time zone. If you went to lunch at 12:00 on that day, you aren't
    going to tell you went to lunch at 11:00 if you tell a story about it
    later in winter (unless it's used as an alibi and you are trying to fool
    a detective).

    So if a file has a June 21st 12:00 timestamp, the computer should always
    display it as June 21st 12:00 as long as it is set up in that time zone,
    whether DST applies or not. Of course, if the computer is configured in
    the next timezone, then the same timestamp can be displayed as June
    21st, 11:00, and this will be the correct display in summer and winter
    in that time zone.

    So yes, Windows is broken
    (<http://www.peterdonis.net/computers/computersarticle3.html>), but
    what's new?

    (*) except for the "duplicate hour" that happens during the fallback night,

    --
    Bertrand
    Ofnuts, Nov 2, 2009
    #4
  5. "Ofnuts" <> wrote in message
    news:4aef509d$0$12528$...
    []
    > So if a file has a June 21st 12:00 timestamp, the computer should always
    > display it as June 21st 12:00 as long as it is set up in that time zone,
    > whether DST applies or not. Of course, if the computer is configured in
    > the next timezone, then the same timestamp can be displayed as June
    > 21st, 11:00, and this will be the correct display in summer and winter
    > in that time zone.

    []
    > Bertrand


    Yes, I can see your argument, but if you take it to its logical
    conclusion, wouldn't you need to include the different time zone of the
    taking device in your calculation of displayed date as well as the time
    zone of the display device, so pictures taken at the same instant would
    show a different timestamp if they were taken in New York, London or
    Paris?

    Cheers,
    David
    David J Taylor, Nov 3, 2009
    #5
  6. bucky3

    Ofnuts Guest

    David J Taylor wrote:
    > "Ofnuts" <> wrote in message news:4aef509d$0$12528$...
    > []
    >> So if a file has a June 21st 12:00 timestamp, the computer should
    >> always display it as June 21st 12:00 as long as it is set up in that
    >> time zone, whether DST applies or not. Of course, if the computer is
    >> configured in the next timezone, then the same timestamp can be
    >> displayed as June 21st, 11:00, and this will be the correct display in
    >> summer and winter in that time zone.

    > []
    >> Bertrand

    >
    > Yes, I can see your argument, but if you take it to its logical
    > conclusion, wouldn't you need to include the different time zone of the
    > taking device in your calculation of displayed date as well as the time
    > zone of the display device, so pictures taken at the same instant would
    > show a different timestamp if they were taken in New York, London or Paris?


    A timestamp is absolute. In computers it is stored as the number of
    seconds (or milliseconds, or nanoseconds) since a reference time (00:00
    UTC on January 1st, 1970 for Unix and a lot of web-related things)(*).
    Whether it is later displayed as June 21st, 12:00 or June 21st, 09:00
    depends only on the "reader". In other words the timezone is nothing
    more than a parameter when displaying or parsing date representations,
    and unless it is implicit (but with computers, "implicit" is seldom a
    good idea) it should be part of the display or input string. Giving a
    time as "2009/11/03 12:00" without a time zone is a bit like giving an
    appointment at 12:00 but not telling which day. So, ideally, your three
    cameras would attach the very same time stamp to the three photos.

    However, the people who did the Exif standard overlooked the
    timezone/DST problem. The timestamp is stored as a "YYYY:MM:DD HH:MM:SS"
    character string, and doesn't include a time zone. So this information
    is lost and if the three cameras above are on local time, they will
    store a different timestamp string. If the standard had provided for a
    time zone, they would have stored something like "2009/11/03 12:00
    UTC+0" in London, "2009/11/03 13:00 UTC+1" in Paris, and "2009/11/03
    07:00 UTC-5" in NY which are three different representations of the very
    same timestamp.

    And the cherry on the cake is that the FAT/FAT32 file system used in
    memory cards uses local time, and files are often transferred between
    camera and computer using a card reader, so unless the camera is
    carefully kept on local time things can get quite fun later, for
    instance when geotagging the pictures.


    (*) see "epoch" on Wikipedia
    --
    Bertrand
    Ofnuts, Nov 3, 2009
    #6
  7. "Ofnuts" <> wrote in message
    news:4af004ab$0$25364$...
    []
    > A timestamp is absolute. In computers it is stored as the number of
    > seconds (or milliseconds, or nanoseconds) since a reference time (00:00
    > UTC on January 1st, 1970 for Unix and a lot of web-related things)(*).


    ... conveniently forgetting about things like leap seconds, perhaps?

    > Whether it is later displayed as June 21st, 12:00 or June 21st, 09:00
    > depends only on the "reader". In other words the timezone is nothing
    > more than a parameter when displaying or parsing date representations,
    > and unless it is implicit (but with computers, "implicit" is seldom a
    > good idea) it should be part of the display or input string.


    Agreed.

    > Giving a time as "2009/11/03 12:00" without a time zone is a bit like
    > giving an appointment at 12:00 but not telling which day. So, ideally,
    > your three cameras would attach the very same time stamp to the three
    > photos.


    That would depend how the users have the cameras set, of course.

    > However, the people who did the Exif standard overlooked the
    > timezone/DST problem. The timestamp is stored as a "YYYY:MM:DD HH:MM:SS"
    > character string, and doesn't include a time zone. So this information
    > is lost and if the three cameras above are on local time, they will
    > store a different timestamp string. If the standard had provided for a
    > time zone, they would have stored something like "2009/11/03 12:00
    > UTC+0" in London, "2009/11/03 13:00 UTC+1" in Paris, and "2009/11/03
    > 07:00 UTC-5" in NY which are three different representations of the very
    > same timestamp.


    ... and once lost, it's gone forever.

    > And the cherry on the cake is that the FAT/FAT32 file system used in
    > memory cards uses local time, and files are often transferred between
    > camera and computer using a card reader, so unless the camera is
    > carefully kept on local time things can get quite fun later, for
    > instance when geotagging the pictures.
    >
    >
    > (*) see "epoch" on Wikipedia
    > --
    > Bertrand


    It can also be fun if:

    - you take pictures before the time-change, and upload them to your
    computer afterwards.

    - you take pictures in one time-zone and upload them in another

    and I'm sure you can think of even more circumstances. For those reasons,
    I keep my camera set to UTC rather than local time, and I don't change it
    between summer and winter. I don't bother about leap seconds on the
    camera, as its clock isn't accurate enough to warrant it.

    It is an important point to know that Windows displays the time with the
    actual date, and the current offset time, rather than the time offset for
    the taking date.

    Cheers,
    David
    David J Taylor, Nov 3, 2009
    #7
  8. bucky3

    Ofnuts Guest

    David J Taylor wrote:
    >
    > "Ofnuts" <> wrote in message news:4af004ab$0$25364$...
    > []
    >> A timestamp is absolute. In computers it is stored as the number of
    >> seconds (or milliseconds, or nanoseconds) since a reference time
    >> (00:00 UTC on January 1st, 1970 for Unix and a lot of web-related
    >> things)(*).

    >
    > .. conveniently forgetting about things like leap seconds, perhaps?


    No, they are taken in account (assuming the display and parsing code are
    correct (mostly the display, since most serious computers
    self-synchronize via NTP).

    >> Whether it is later displayed as June 21st, 12:00 or June 21st, 09:00
    >> depends only on the "reader". In other words the timezone is nothing
    >> more than a parameter when displaying or parsing date representations,
    >> and unless it is implicit (but with computers, "implicit" is seldom a
    >> good idea) it should be part of the display or input string.

    >
    > Agreed.
    >
    >> Giving a time as "2009/11/03 12:00" without a time zone is a bit like
    >> giving an appointment at 12:00 but not telling which day. So, ideally,
    >> your three cameras would attach the very same time stamp to the three
    >> photos.

    >
    > That would depend how the users have the cameras set, of course.


    This assumes that the cameras would have a way to know the "absolute"
    time (ie, set to UTC, or given a timezone).

    > It is an important point to know that Windows displays the time with the
    > actual date, and the current offset time, rather than the time offset
    > for the taking date.
    >


    Not even sure of the date part. If a file is stamped at 00:30 on June
    21st, will Window show it later as stamped at 23:30 on June 21st or at
    23:30 on June 20th?

    --
    Bertrand
    Ofnuts, Nov 3, 2009
    #8
  9. bucky3

    Dave Cohen Guest

    Ofnuts wrote:
    > David J Taylor wrote:
    >>
    >> "Ofnuts" <> wrote in message
    >> news:4af004ab$0$25364$...
    >> []
    >>> A timestamp is absolute. In computers it is stored as the number of
    >>> seconds (or milliseconds, or nanoseconds) since a reference time
    >>> (00:00 UTC on January 1st, 1970 for Unix and a lot of web-related
    >>> things)(*).

    >>
    >> .. conveniently forgetting about things like leap seconds, perhaps?

    >
    > No, they are taken in account (assuming the display and parsing code are
    > correct (mostly the display, since most serious computers
    > self-synchronize via NTP).
    >
    >>> Whether it is later displayed as June 21st, 12:00 or June 21st, 09:00
    >>> depends only on the "reader". In other words the timezone is nothing
    >>> more than a parameter when displaying or parsing date
    >>> representations, and unless it is implicit (but with computers,
    >>> "implicit" is seldom a good idea) it should be part of the display or
    >>> input string.

    >>
    >> Agreed.
    >>
    >>> Giving a time as "2009/11/03 12:00" without a time zone is a bit like
    >>> giving an appointment at 12:00 but not telling which day. So,
    >>> ideally, your three cameras would attach the very same time stamp to
    >>> the three photos.

    >>
    >> That would depend how the users have the cameras set, of course.

    >
    > This assumes that the cameras would have a way to know the "absolute"
    > time (ie, set to UTC, or given a timezone).
    >
    >> It is an important point to know that Windows displays the time with
    >> the actual date, and the current offset time, rather than the time
    >> offset for the taking date.
    >>

    >
    > Not even sure of the date part. If a file is stamped at 00:30 on June
    > 21st, will Window show it later as stamped at 23:30 on June 21st or at
    > 23:30 on June 20th?
    >


    There is no easy universal way around these problems. Fortunately in the
    grand scheme of things it's not a big deal as long as you are aware of
    what's happening. If one is that picky, set the camera to UTC, keep it
    that way and just do a mental adjustment as needed.
    Dave Cohen, Nov 3, 2009
    #9
  10. bucky3

    Toxic Guest

    On Tue, 03 Nov 2009 13:56:43 +0000, David J Taylor wrote:

    > I keep my camera set to UTC rather than local time



    Good idea,
    and since I've got to go in and dither its clock one of these days,
    I think I'll do likewise.
    Toxic, Nov 3, 2009
    #10
  11. bucky3

    bucky3 Guest

    Thanks everyone, that was quite an educational thread.

    Just curious, how do other operating systems (like Unix, Mac) handle
    the file timestamp in regards to DST? Do they have the same problem,
    or do they handle it better?
    bucky3, Nov 3, 2009
    #11
  12. bucky3

    Eric Stevens Guest

    On Tue, 3 Nov 2009 20:57:14 +0000 (UTC), Toxic <staring@my_hd.tv>
    wrote:

    >On Tue, 03 Nov 2009 13:56:43 +0000, David J Taylor wrote:
    >
    >> I keep my camera set to UTC rather than local time

    >
    >
    >Good idea,
    >and since I've got to go in and dither its clock one of these days,
    >I think I'll do likewise.


    My camera (Nikon D300) is set to synchronise time with my computer
    every time I connect the two. The computer (Windows XP) shows local
    time, including the adjustment for DST. It also is synchronised daily
    with a time signal from somewhere (USN Hawaii?) All of this is very
    convenient and much more meaningful than me having to maintain my
    camera at UTC.



    Eric Stevens
    Eric Stevens, Nov 3, 2009
    #12
  13. bucky3

    nospam Guest

    In article <2009110313342154666-savageduck1@REMOVESPAMmecom>,
    Savageduck <savageduck1@{REMOVESPAM}me.com> wrote:

    > > Just curious, how do other operating systems (like Unix, Mac) handle
    > > the file timestamp in regards to DST? Do they have the same problem,
    > > or do they handle it better?

    >
    > Apple provides an option for automatic date & time setting via one of 3
    > online time servers; Apple Americas/U.S. (time.apple.com); Apple Asia
    > (time.asia.apple.com); Apple Europe (time.euro.apple.com) this
    > automatically handles all DST issues.


    other time servers can be added and the time stamp is utc with a time
    zone offset.
    nospam, Nov 3, 2009
    #13
  14. Savageduck <savageduck1@{REMOVESPAM}me.com> wrote:
    >On 2009-11-03 13:25:30 -0800, bucky3 <> said:
    >
    >> Thanks everyone, that was quite an educational thread.
    >>
    >> Just curious, how do other operating systems (like Unix, Mac) handle
    >> the file timestamp in regards to DST? Do they have the same problem,
    >> or do they handle it better?

    >
    >Apple provides an option for automatic date & time setting via one of 3
    >online time servers; Apple Americas/U.S. (time.apple.com); Apple Asia
    >(time.asia.apple.com); Apple Europe (time.euro.apple.com) this
    >automatically handles all DST issues.


    So does Microsoft. And other organizations. But the time transmitted is
    always UTC and any time zone settings are handled locally on your
    computer according to your timezone settings. After all, how would the
    server know if you are on the left side or right side of that time zone
    border.

    jue
    Jürgen Exner, Nov 3, 2009
    #14
  15. bucky3

    Ofnuts Guest

    bucky3 wrote:
    > Thanks everyone, that was quite an educational thread.
    >
    > Just curious, how do other operating systems (like Unix, Mac) handle
    > the file timestamp in regards to DST? Do they have the same problem,
    > or do they handle it better?


    I believe the Unix-based systems (Linux, OSX, BSD) handle it correctly.


    --
    Bertrand
    Ofnuts, Nov 3, 2009
    #15
  16. bucky3

    Ofnuts Guest

    Eric Stevens wrote:
    > On Tue, 3 Nov 2009 20:57:14 +0000 (UTC), Toxic <staring@my_hd.tv>
    > wrote:
    >
    >> On Tue, 03 Nov 2009 13:56:43 +0000, David J Taylor wrote:
    >>
    >>> I keep my camera set to UTC rather than local time

    >>
    >> Good idea,
    >> and since I've got to go in and dither its clock one of these days,
    >> I think I'll do likewise.

    >
    > My camera (Nikon D300) is set to synchronise time with my computer
    > every time I connect the two. The computer (Windows XP) shows local
    > time, including the adjustment for DST. It also is synchronised daily
    > with a time signal from somewhere (USN Hawaii?) All of this is very
    > convenient and much more meaningful than me having to maintain my
    > camera at UTC.


    It's also a lot easier if you geotag your photos using a GPS log file.

    --
    Bertrand
    Ofnuts, Nov 3, 2009
    #16
  17. bucky3 <> wrote:
    >Just curious, how do other operating systems (like Unix, Mac) handle
    >the file timestamp in regards to DST?


    It's not an issue because all times/dates are stored in UTC (or actually
    seconds since the epoch) and converted to local time for display
    purposes only.

    >Do they have the same problem,
    >or do they handle it better?


    Not sure how you define "problem" and "better". The exact time is
    available, it is up to you as a user to decide how you want to display
    it.

    I think your problem is not a problem at all. Or maybe it's a problem
    where there is no meaningful solution. Or maybe you didn't think it
    through all the way. DST is only one very small factor in dealing with
    local time.

    Example: If photos have been taken in Sydney at lunch time and now you
    are looking at those files back home in NewYork, what time stamp would
    you expect: 13:00 (the local time at the place those files were created)
    or 22:00 the previous day (the local time of when the files were created
    at the place you are looking at the files now)?
    Now imagine that you uploaded those files minutes after you took them to
    your home server in NY, and another family member uploaded some other
    photos locally in NY 2 hours later. What time sequence would you like to
    see: your photos first or his photos first? Because by local time based
    on where the photos were taken his would be first by 13 hours although
    they were taken 2 hours after yours.

    So no, there is no golden bullet and the only sensible option is indeed
    using UTC and thus having an absolut target, that is not moving with
    crossing each time zone boundary and not moving with every switch
    between DST and non-DST, either.

    jue
    Jürgen Exner, Nov 4, 2009
    #17
  18. "Eric Stevens" <> wrote in message
    news:...
    []
    > My camera (Nikon D300) is set to synchronise time with my computer
    > every time I connect the two. The computer (Windows XP) shows local
    > time, including the adjustment for DST. It also is synchronised daily
    > with a time signal from somewhere (USN Hawaii?) All of this is very
    > convenient and much more meaningful than me having to maintain my
    > camera at UTC.
    >
    > Eric Stevens


    If you want better than a daily sync, look at NTP:

    http://www.meinberg.de/english/sw/ntp.htm

    You can keep your PC within a fraction of a second using an Internet
    connection.

    Cheers,
    David
    David J Taylor, Nov 4, 2009
    #18
  19. "Ofnuts" <> wrote in message
    news:4af044f8$0$30818$...
    > David J Taylor wrote:
    >>
    >> "Ofnuts" <> wrote in message
    >> news:4af004ab$0$25364$...
    >> []
    >>> A timestamp is absolute. In computers it is stored as the number of
    >>> seconds (or milliseconds, or nanoseconds) since a reference time
    >>> (00:00 UTC on January 1st, 1970 for Unix and a lot of web-related
    >>> things)(*).

    >>
    >> .. conveniently forgetting about things like leap seconds, perhaps?

    >
    > No, they are taken in account (assuming the display and parsing code are
    > correct (mostly the display, since most serious computers
    > self-synchronize via NTP).


    Unix time ignores leap seconds, at least according to:

    http://en.wikipedia.org/wiki/Unix_time

    and that's my experience as well. The "number of seconds" does /not/
    include the leap seconds. To test, try seeing whether the Unix time tor
    the start of a day is exactly divisible by 86400 - e.g. 1257292800
    (4-Nov-2009 at 00:00:00). If Unix time included the leap-second count,
    the start of a day should be n * 86400 + 24. (IIRC).

    []
    > Not even sure of the date part. If a file is stamped at 00:30 on June
    > 21st, will Window show it later as stamped at 23:30 on June 21st or at
    > 23:30 on June 20th?
    >
    > --
    > Bertrand


    An interesting point, although to some extent one I face all the time as,
    for example, most of my "daytime" photographs taken in Australia cover
    two UTC calendar days. As my camera and hence my EXIF information stays
    on UTC, the photos have a continually increasing sequence number when
    renamed, even over a winter/summer time change. My photos have a name -
    typically:

    2009-09-24-0826-57.jpg

    Cheers,
    David
    David J Taylor, Nov 4, 2009
    #19
  20. bucky3

    J. Clarke Guest

    David J Taylor wrote:
    > "Eric Stevens" <> wrote in message
    > news:...
    > []
    >> My camera (Nikon D300) is set to synchronise time with my computer
    >> every time I connect the two. The computer (Windows XP) shows local
    >> time, including the adjustment for DST. It also is synchronised daily
    >> with a time signal from somewhere (USN Hawaii?) All of this is very
    >> convenient and much more meaningful than me having to maintain my
    >> camera at UTC.
    >>
    >> Eric Stevens

    >
    > If you want better than a daily sync, look at NTP:
    >
    > http://www.meinberg.de/english/sw/ntp.htm
    >
    > You can keep your PC within a fraction of a second using an Internet
    > connection.


    You don't need "NTP for Windows" with Windows you know. The Windows Time
    Service is quite capable of synchronizing to an NTP server, and in fact
    Vista does that out of the box unless it's on a domain, in which case it
    synchronizes to the domain controller.

    On XP and earlier you have to do some digging to set it up, on Vista it's
    set up right off the clock application in the system tray on the lower
    right. For XP the procedure can be found at
    http://support.microsoft.com/kb/314054#EXTERNAL. There's a link from there
    to the procedure for Windows 2000.
    J. Clarke, Nov 4, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrew Barnes

    Daylight Savings time configuration

    Andrew Barnes, Mar 23, 2006, in forum: Cisco
    Replies:
    2
    Views:
    1,990
    thrill5
    Mar 24, 2006
  2. Jim Kroger
    Replies:
    2
    Views:
    1,089
    Brian H¹©
    Oct 14, 2003
  3. XtremeHOHA

    Daylight savings time......

    XtremeHOHA, Jan 14, 2005, in forum: Computer Support
    Replies:
    5
    Views:
    652
    Tim K.
    Jan 15, 2005
  4. Newsguy

    Daylight Savings Time Impact

    Newsguy, Jan 17, 2007, in forum: Cisco
    Replies:
    6
    Views:
    488
    Loren Amelang
    Jan 25, 2007
  5. Phil

    Daylight Savings Time Change

    Phil, Feb 18, 2007, in forum: Computer Support
    Replies:
    4
    Views:
    447
Loading...

Share This Page