bug#16606: date command throws error when DST is turned on

2014-01-30 Thread Lakshmi Ramamurthi -X (lramamur - HCL TECHNOLOGIES LIMITED at Cisco)
Hi,

The date command throws error when the DST is turned on.

# date +%s -d 2013/11/20
1384912800
# date +%s -d 2013/10/20
date: invalid date `2013/10/20'

1 sec after Oct 19 23:59:59 2013 becomes Oct 20 01:00:00 2013
As there is no 0th hour on Oct 20, it shows invalid date.

Are there any options to fix this problems ?
Has there been a patch posted for this.


#date
Sun Mar 10 07:02:07 BRT 2013

# zdump -v /etc/localtime | grep 2013
/etc/localtime Sun Feb 17 01:59:59 2013 UTC = Sat Feb 16 23:59:59 2013 BRST 
isdst=1 gmtoff=-7200
/etc/localtime Sun Feb 17 02:00:00 2013 UTC = Sat Feb 16 23:00:00 2013 BRT 
isdst=0 gmtoff=-10800
/etc/localtime Sun Oct 20 02:59:59 2013 UTC = Sat Oct 19 23:59:59 2013 BRT 
isdst=0 gmtoff=-10800
/etc/localtime Sun Oct 20 03:00:00 2013 UTC = Sun Oct 20 01:00:00 2013 BRST 
isdst=1 gmtoff=-7200

Thanks,
Lakshmi


bug#16578: Wish: Support for non-native endianness in od

2014-01-30 Thread Niels Möller
Pádraig Brady p...@draigbrady.com writes:

 On 01/28/2014 12:54 PM, Niels Möller wrote:
 For the od program, it would be nice with a flag to specify the
 endianness for all types which are larger than a byte. Possible
 alternatives could be big endian, little endian, native endian.

 I agree this would be useful and easy enough to add.
 I suppose the interface would be --endian=little|big

Maybe I can have a look at what it takes.

 And for floats, besides endianness, it would be nice to be able to
 specify native format or ieee format, for systems where these are
 different.

 That's a bit less useful I think and harder to implement.

I agree that's a bit more obscure. So I understand if you don't want to do
that until there's some concrete usecase.

Endianness for float types should be easier, I hope.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.





bug#16606: date command throws error when DST is turned on

2014-01-30 Thread Bob Proulx
tag 16606 +notabug
close 16606
thanks

Lakshmi Ramamurthi -X (lramamur - HCL TECHNOLOGIES LIMITED at Cisco) wrote:
 The date command throws error when the DST is turned on.
 
 # date +%s -d 2013/11/20
 1384912800
 # date +%s -d 2013/10/20
 date: invalid date `2013/10/20'

 1 sec after Oct 19 23:59:59 2013 becomes Oct 20 01:00:00 2013
 As there is no 0th hour on Oct 20, it shows invalid date.

You are completely correct that there is no midnight in your timezone
and therefore the date you are requesting *in your timezone* does not
exist and therefore it is an invalid date.  The date command is
working correctly in reporting it as an invalid date.  I will
emphasize that this is timezone specific behavior.

 Are there any options to fix this problems ?
 Has there been a patch posted for this.

The option to fix this is the -u option to select UTC.  No patches are
needed.

The best choice is to work with dates in the UTC timezone which avoids
all DST issues since UTC never changes and never skips seconds.  The
second best choice is to work with times around noon which avoids DST
time changes that usually happen at night.  These hints are discussed
in the FAQ entry in more detail.

You didn't say what specific timezone you were concerned with so I
will pick one at random for an example.

  $ env TZ=America/Sao_Paulo date -R -d 2013/10/20
  date: invalid date ‘2013/10/20’

That date at midnight does not exist in that timezone.

  $ env TZ=America/Sao_Paulo date -R -d 2013/10/20 12:00
  Sun, 20 Oct 2013 12:00:00 -0200

Using 12:00 noon avoids the skipped interval.

  $ date -u -R -d 2013/10/20
  Sun, 20 Oct 2013 00:00:00 +

Using UTC avoids the problem because UTC doesn't skip intervals for
DST.  I also didn't show setting a default timezone (TZ) because that
is also not matter when using UTC.  It is just simpler all around.

Please see the FAQ entry where this is explained in detail.

  
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

Bob





bug#16606: date command throws error when DST is turned on

2014-01-30 Thread Lakshmi Ramamurthi -X (lramamur - HCL TECHNOLOGIES LIMITED at Cisco)
Thanks a lot for your quick reply.

-Lakshmi

-Original Message-
From: Bob Proulx [mailto:b...@proulx.com] 
Sent: Friday, January 31, 2014 12:47 PM
To: Lakshmi Ramamurthi -X (lramamur - HCL TECHNOLOGIES LIMITED at Cisco)
Cc: 16...@debbugs.gnu.org
Subject: Re: bug#16606: date command throws error when DST is turned on

tag 16606 +notabug
close 16606
thanks

Lakshmi Ramamurthi -X (lramamur - HCL TECHNOLOGIES LIMITED at Cisco) wrote:
 The date command throws error when the DST is turned on.
 
 # date +%s -d 2013/11/20
 1384912800
 # date +%s -d 2013/10/20
 date: invalid date `2013/10/20'

 1 sec after Oct 19 23:59:59 2013 becomes Oct 20 01:00:00 2013 As there 
 is no 0th hour on Oct 20, it shows invalid date.

You are completely correct that there is no midnight in your timezone and 
therefore the date you are requesting *in your timezone* does not exist and 
therefore it is an invalid date.  The date command is working correctly in 
reporting it as an invalid date.  I will emphasize that this is timezone 
specific behavior.

 Are there any options to fix this problems ?
 Has there been a patch posted for this.

The option to fix this is the -u option to select UTC.  No patches are needed.

The best choice is to work with dates in the UTC timezone which avoids all DST 
issues since UTC never changes and never skips seconds.  The second best choice 
is to work with times around noon which avoids DST time changes that usually 
happen at night.  These hints are discussed in the FAQ entry in more detail.

You didn't say what specific timezone you were concerned with so I will pick 
one at random for an example.

  $ env TZ=America/Sao_Paulo date -R -d 2013/10/20
  date: invalid date ‘2013/10/20’

That date at midnight does not exist in that timezone.

  $ env TZ=America/Sao_Paulo date -R -d 2013/10/20 12:00
  Sun, 20 Oct 2013 12:00:00 -0200

Using 12:00 noon avoids the skipped interval.

  $ date -u -R -d 2013/10/20
  Sun, 20 Oct 2013 00:00:00 +

Using UTC avoids the problem because UTC doesn't skip intervals for DST.  I 
also didn't show setting a default timezone (TZ) because that is also not 
matter when using UTC.  It is just simpler all around.

Please see the FAQ entry where this is explained in detail.

  
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

Bob