in reply to Re^3: Date Time problem.
in thread Date Time problem.

As previously mentioned, I don't think leap seconds matter with time. In any case, I'm talking of the days with 23*60*60 seconds and the days with 25*60*60 seconds.

Previously written example: 

# Set your timezone to America/New_York before running.
# In this time zone, DST ends on Nov 2, 2008 at 2:00 AM.

# "Sets" the current time to 5 seconds past midnight on Oct 28, 2008.
use Time::Local qw( timelocal );
my $time = timelocal(5,0,0,28,10-1,2008);

use POSIX;
print( strftime( "%m-%d\n", localtime( (24*60*60) * $_ + $time ) ) )
   for 1..30;

[download]

Output 

10-29
10-30
10-31
11-01
11-02   \ 11-02 seen twice
11-02   /
11-03
11-04
11-05
11-06
11-07
11-08
11-09
11-10
11-11
11-12
11-13
11-14
11-15
11-16
11-17
11-18
11-19
11-20
11-21
11-22
11-23
11-24
11-25
11-26
       > 11-27 never seen

[download]

You don't need any inefficient code to do it right, so you might as well do it right. Sewi showed a way that will probably always work. The following will always work: 

use Time::Local qw( timegm );
use POSIX qw( strftime );
my $date = timegm(localtime);
$date += 24*60*60;
print(strftime("%Y%m%d\n", gmtime($date)));

[download]

GMT always has 24*60*60 seconds per day. Note the result is still local time.

Replies are listed 'Best First'.
Re^5: Date Time problem.
by Marshall (Canon) on Sep 05, 2009 at 06:35 UTC
    When logging times, I use GMT.
    strftime() is an expensive critter in terms of perforance. BUT, expensive is relative and often this does not matter. Use if it you want to. Other ways shown below. 
    #!/usr/bin/perl -w
use strict;
use Time::Local;

# Sets the current time to 5 seconds past midnight on Oct 28, 2008.

my $start_time = timelocal(5,0,0,28,10-1,2008);
my $start_time_string = localtime($start_time);
print "Local time=$start_time_string\n";  #Tue Oct 28 00:00:05 2008

foreach my $delta_days (1..35)
{ 
   my $new_time = $start_time;
   $new_time = $start_time + ($delta_days*24*60*60);
   my $new_time_string = gmtime($new_time);
   print "$new_time_string\n";
}

__END__
OUTPUT:
Local time=Tue Oct 28 00:00:05 2008
Wed Oct 29 07:00:05 2008
Thu Oct 30 07:00:05 2008
Fri Oct 31 07:00:05 2008
Sat Nov  1 07:00:05 2008
Sun Nov  2 07:00:05 2008
Mon Nov  3 07:00:05 2008
Tue Nov  4 07:00:05 2008
Wed Nov  5 07:00:05 2008
Thu Nov  6 07:00:05 2008
Fri Nov  7 07:00:05 2008
Sat Nov  8 07:00:05 2008
Sun Nov  9 07:00:05 2008
Mon Nov 10 07:00:05 2008
Tue Nov 11 07:00:05 2008
Wed Nov 12 07:00:05 2008
Thu Nov 13 07:00:05 2008
Fri Nov 14 07:00:05 2008
Sat Nov 15 07:00:05 2008
Sun Nov 16 07:00:05 2008
Mon Nov 17 07:00:05 2008
Tue Nov 18 07:00:05 2008
Wed Nov 19 07:00:05 2008
Thu Nov 20 07:00:05 2008
Fri Nov 21 07:00:05 2008
Sat Nov 22 07:00:05 2008
Sun Nov 23 07:00:05 2008
Mon Nov 24 07:00:05 2008
Tue Nov 25 07:00:05 2008
Wed Nov 26 07:00:05 2008
Thu Nov 27 07:00:05 2008
Fri Nov 28 07:00:05 2008
Sat Nov 29 07:00:05 2008
Sun Nov 30 07:00:05 2008
Mon Dec  1 07:00:05 2008
Tue Dec  2 07:00:05 2008

    [download]
[reply]
[d/l]
      That assumes the date is the same for GMT and local. That's 410 times worse than your original solution. You took a solution that was wrong maybe 4 hours a year and made it into a solution that's wrong 4 or 5 hours a day. (For me. Error will vary based on local time zone).

      nm, I get it. Printing the wrong starting date confused me.

      I'm not sure if that's an acceptable solution here. When dealing with a timestamp, sure. Dates, not so much.

[reply]
        I think that GMT is the only reasonable way to deal with date/times in complex applications. I may wind up with log files from 5,7 even more different time zones and have to make a report. This is easier if everybody is "talking about the same kind of time". UTC, GMT, Zulu time is time that means the same thing across time zones (and daylight savings time weirdness).

        You may think that the US only has 4 time zones, (Pacific, Mountain, Central, Eastern) but there are actually 4 others! http://www.time.gov/ will show the 8 time zones for the US (includes territories and commonwealths).

        Russia has 11 time zones. France and England are in different time zones although many Americans would think that this is just "Europe". The Irish folks will get really upset about this!

        I strongly recommend the use of GMT for log data date/time stamps. Converting these date/times to a presentation layer is a separate thing. Maybe the guy in France gets a different looking report from the guy in New York,USA. But log the data so that you can easily generate all of these different reports.

[reply]

In Section Seekers of Perl Wisdom