The UNIX epoch timestamp, being the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1, 1970, not counting leap seconds has no problems with daylight savings time adjustments. That is something you will have to look into only at the level of printing "human readable" output for a particular time-zone.The internal format is therefore best left and stored as a timestamp and converted into whatever you need upon preparing the output. The docs at DateTime say: use UTC for all calculations
If you do care about time zones (particularly DST) or leap seconds, try to use non-UTC time zones for presentation and user input only. Convert to UTC immediately and convert back to the local time zone for presentation: Arguably DateTime is the best for making such conversions, but yes it is a heavy and relatively slow module, but you pay that price only once at start-up.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
| [reply] |
Ok, I went through the replies just now, and did some google also. For my need I actually do not need to use any modules. I have a very simple requirement!
Here is the code I wrote.
In this I have put incrtime as 1 sec, but I can put any number of seconds I want, so no issues there!
#!/usr/bin/perl
use strict;
my $lat = 23.438;
my $slon= 68.000;
my $elon= 90.000;
my $clon = $slon;
my $incrlon= 0.01;
my $time = time;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($
+time) ;
my $incrtime=1;
my $printmon;
my $printyear;
open OUTFILE,">tropic_of_cancer.gpx" or die \"Cannot open file for wri
+ting\n";
print \"Printing Header...\n";
print OUTFILE "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"n
+o\"?>\n";
print OUTFILE "<gpx version=\"1.1\" creator=\"MakeTropic\" xmlns=\"htt
+p://www.topografix.com/GPX/1/1\" xmlns:xsi=\"http://www.w3.org/2001/X
+MLSchema-instance\" xsi:schemaLocation=\"http://www.topografix.com/GP
+X/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd\">\n";
print OUTFILE "<trk>\n";
print OUTFILE " <name>Tropic of Cancer</name>\n";
while ($clon < $elon) {
$printmon = $mon+1;
$printyear = $year+1900;
print OUTFILE " <trkseg>\n";
printf OUTFILE (" <trkpt lat=\"%.3f\" lon=\"%.3f\">\n",
+$lat,$clon);
print OUTFILE " <time>$printyear-$printmon-$mday"."
+T"."$hour:$min:$sec"."Z"."</time>\n";
print OUTFILE " </trkpt>\n";
$clon=$clon+$incrlon;
$time=$time+$incrtime;
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(
+$time) ;
}
print OUTFILE " </trkseg>\n";
print OUTFILE " </trk>\n";
print OUTFILE "</gpx>";
close OUTFILE;
It works fast and is tiny. | [reply]
[d/l] |
It works fast and is tiny.
I beg to differ. It is both slow and verbose. DateTime is 10 times faster, and Date::Calc is 700 times faster!
It is a good habit to Benchmark your code before making bold claims about its performance.
--
No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]
| [reply]
[d/l] |
What? You're going to compare 16 lines of unrelated code (which contains a nasty loop) to a single line function and call it a benchmark victory? The OP was looking for a quick date time increment. His solution contained this and plenty of other code not directly related to the date time increment. If you're going to benchmark you won't get very far comparing apples to oranges.
By my benchmarking, the OP's "equivalent datetime increment" code is 144 times faster than DateTime and nearly as fast as Date::Calc.
It's a good habit to check that your Benchmark code is equivalent before making bold claims about your Benchmark results.
| [reply]
[d/l] |