| Summary: | Invalid local time for date in time zone: America/Sao_Paulo | ||
|---|---|---|---|
| Product: | Red Hat Satellite 5 | Reporter: | Waldirio M Pinheiro <wpinheir> |
| Component: | Server | Assignee: | Tomáš Kašpárek <tkasparek> |
| Status: | CLOSED DEFERRED | QA Contact: | Red Hat Satellite QA List <satqe-list> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 570 | CC: | tlestach, wpinheir |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-06-09 15:40:14 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
We have re-reviewed this bug, as part of an ongoing effort to improve Satellite/Proxy feature and bug updates, review and backlog. This is a low priority bug and has no currently open customer cases. While this bug may still valid, we do not see it being implemented prior to the EOL of the Satellite 5.x product. As such, this is being CLOSED DEFERRED. Closing now to help set customer expectations as early as possible. You are welcome to re-open this bug if needed. |
Description of problem: Hi, customer is facing issue when scheduling some tasks to be executed exactly at the same day when OS will change the time *DST*. The way that we found to figure out and *probably* get the issue was executing one perl script and when we define the time frame between 0:0:0h to 0:59:59 we receive the error below, after this, come back work normally. --- [root@satellite5 dst]# TZ="America/Sao_Paulo" perl test.pl Invalid local time for date in time zone: America/Sao_Paulo [root@satellite5 dst]# --- Version-Release number of selected component (if applicable): Testing with RHEL6.x How reproducible: 100 Steps to Reproduce: 1. Create the code below --- #!/usr/bin/perl use DateTime; ############## sub unixtime { ############## my $timestamp = shift; my($year, $month, $day, $hour, $min, $sec) = split(/\s+/, $timestamp); my $dt = DateTime->new( year => $year, month => $month, day => $day, hour => $hour, minute => $min, second => $sec, time_zone => 'local' ); return $dt->epoch; } my $t = unixtime('2016 10 16 00 00 00'); print "$t\n"; print scalar(localtime $t), "\n"; --- 2. Execute the command below --- [root@satellite5 dst]# TZ="America/Sao_Paulo" perl test.pl Invalid local time for date in time zone: America/Sao_Paulo You have new mail in /var/spool/mail/root [root@satellite5 dst]# --- 3. Change internally to '2016 10 12 00 59 59' and rerun the command --- [root@satellite5 dst]# TZ="America/Sao_Paulo" perl test.pl Invalid local time for date in time zone: America/Sao_Paulo [root@satellite5 dst]# --- 4. Change to '2016 10 12 01 00 00' and rerun --- [root@satellite5 dst]# TZ="America/Sao_Paulo" perl test.pl 1476586800 Sun Oct 16 01:00:00 2016 [root@satellite5 dst]# --- So probably Satellite use this reference to schedule or execute some tasks and during this time, it's not possible to schedule or execute any task. Actual results: Tasks doesn't executed. Expected results: Execute task normally. Additional info: