in reply to Re^4: Converting local time to utc time
in thread Converting local time to utc time

Didn't fully understand that paragraph when I first read it! Given that I cannot change the source local datetime - is there anyway I can convert these ambiguous date times into UTC?

Kind of feel I'm back to my original question... given a local date time for the entire year incrementing by 1 minute each time how can I convert this local time into UTC time and get correct results, even during the ambiguous date time period when the local date time changes from Daylight Saving Time and back again?
  • Comment on Re^5: Converting local time to utc time

Replies are listed 'Best First'.
Re^6: Converting local time to utc time
by soonix (Chancellor) on Nov 12, 2014 at 08:23 UTC

    The problem is: if you have a timestamp of "2003-10-26 01:17:47 Local Time", you actually have incomplete information. Only if you can distinguish(*) between "Local Time (Summer)" and "Local Time (Winter)", you have a chance to getting the right results here.

    Does your CSV source contain that info?

    Otherwise it will become guesswork, e.g. you could assume that the transition between summer and "normal" time (as I like to call it) is marked by a record with a time stamp earlier than its predecessor.

    (*) ... and can give this bit to the converting (sub)routine
      I might need to code round this with the information I have. I only have a date/time (per minute) and a series of associated weather parameters, temp, wind etc.

      These records come in sequence, as the local time changes, going from BST to GMT(UTC) or back the local time either repeats an hour or misses an hour. If I can detect this change (i.e. work out the day the clocks change) then I can probably build in the correct (duplicate/missing) times. The clock change always occurs during a given hour on variable days - it's always GMT/BST times in the source data.

      I was hoping that this module would do this for me, but if not then I'll need to go away and think about how to build a solution. But, will need to think how I'm going to do it!

        The change forward is not a problem, it's moving back that creates the ambiguity. As I see it you need to delay applying the UTC timezone until the second sequence of 01:00 to 01:59 times on the change day. I suggest using the is_DST method to detect the change, and a hash to remember when the time repeats. For example :

        #!perl use DateTime; use DateTime::TimeZone; use strict; my %seen=(); my $tz = 'UTC'; my $last; while (<DATA>){ chomp; next unless ($_); my ($y,$m,$d,$hr,$min) = split /\D/,$_; print "$_ : "; my $dt = DateTime->new ( year => $y, month => $m, day => $d, hour => $hr, minute => $min, time_zone => 'Europe/London', ); print $dt->is_dst," : "; if ($m==10 && $hr==1){ if ($dt->is_dst() ne $last){ $tz = '-1:00'; } $tz = 'UTC' if ++$seen{$min} > 1; } else { %seen=(); } $last = $dt->is_dst(); $dt->set_time_zone($tz); print $dt->strftime("%Y-%m-%d %H:%M")," $tz \n"; } __DATA__ 2014-03-30 00:59 2014-03-30 02:00 2014-03-30 02:01 2014-03-30 02:30 2014-03-30 02:59 2014-03-30 03:00 2014-03-30 03:01 2014-03-30 03:30 2014-03-30 03:59 2014-03-30 04:00 2014-03-30 04:01 2014-03-30 04:02 2014-10-26 00:59 2014-10-26 01:00 2014-10-26 01:01 2014-10-26 01:30 2014-10-26 01:59 2014-10-26 01:00 2014-10-26 01:01 2014-10-26 01:30 2014-10-26 01:59 2014-10-26 02:00 2014-10-26 02:01 2014-10-26 02:02