Rainer Zocholl a ?crit : > Sergei.Haller@xxxxxxxxxxxxxxxxxxx(Sergei Haller) 01.06.05 17:16 > >>no. time_t is the number of seconds since 1970-01-01 in UTC. >>a time value as time_t is _unique_. > >>the call >> date -d "1970-01-01 1117634400 sec" > >>is _not_ translation from time_t to human readable time. >>you are kind of "cheating" telling date to recalculate the time >>"1970-01-01 00:00:1117634400" in whatever time zone it expectes it. > > That "cheat" is documented in some man pages for (GNU) "date". Well, it seems that using "date" adds the complexity of time-zone handling to the simple date-difference calculation. There is the from-TZ, the to-TZ, the fact that summer-time is either applied to the date you provide (1970-01-01) or the date resulting from the calculation (now in "summer")... Avoid the problem is one way to solve it : just make sure you do not deal with time-zones when you want to make date calculations. Your samples with UTC *and* --utc seems all correct... Then apply you time-zone adjustments, or consider your clock (hardware-clock) is UTC (as recommended by every Linux admin), and voil?... > "info date" says: > > * To convert a date string to the number of seconds since the epoch > (which is 1970-01-01 00:00:00 UTC), use the `--date' option with > the `%s' format. That can be useful in sorting and/or graphing > and/or comparing data by date. The following command outputs the > number of the seconds since the epoch for the time two minutes > after the epoch: > > date --date='1970-01-01 00:02:00 +0000' +%s > 120 > > If you do not specify time zone information in the date string, > `date' uses your computer's idea of the time zone when > interpreting the string. For example, if your computer's time > zone is that of Cambridge, Massachusetts, which was then 5 hours > (i.e., 18,000 seconds) behind UTC: > > # local time zone used > date --date='1970-01-01 00:02:00' +%s > 18120 > > * If you're sorting or graphing dated data, your raw date values may > be represented as seconds since the epoch. But few people can > look at the date `946684800' and casually note "Oh, that's the > first second of the year 2000 in Greenwich, England." > > date --date='2000-01-01 UTC' +%s > 946684800 > > An alternative is to use the `--utc' (`-u') option. Then you may > omit `UTC' from the date string. Although this produces the same > result for `%s' and many other format sequences, with a time zone > offset different from zero, it would give a different result for > zone-dependent formats like `%z'. > > date -u --date=2000-01-01 +%s > 946684800 > > > *To convert such an unwieldy number of seconds back to a more* > *readable form, use a command like this:* > > # local time zone used > date -d '1970-01-01 UTC 946684800 seconds' +"%Y-%m-%d %T %z" > 1999-12-31 19:00:00 -0500 > > Often it is better to output UTC-relative date and time: > > date -u -d '1970-01-01 946684800 seconds' +"%Y-%m-%d %T %z" > 2000-01-01 00:00:00 +0000 > > > I don't see why this is a "cheat" (= not intended way of usesage) > and why it should be required to have "self programming" such function. > Of cause the risc of errors is low if all use exactly teh same > routine. > > > > The man page example is missleading. > date will interpret the "1970-01-01" with the current timezone... > > It must read: > # date -d "1970-01-01 UTC 1117634400 sec" > Wed Jun 1 16:00:00 CEST 2005 > as the "-utc" relates to output. > # date -u -d "1970-01-01 UTC 1117634400 sec" > Wed Jun 1 14:00:00 UTC 2005 > > But i still do not undestand why here is a 1h offset > if nothing is given. > I would assuem that the timezone would be komensated > # date -d "1970-01-01 1117634400 sec" > Wed Jun 1 15:00:00 CEST 2005 > > > > > BTW: > # date -u -d "1970-01-01 1117634400 sec " > Wed Jun 1 14:00:00 UTC 2005 > > # date -u -d "1970-01-01 1117634400 sec GMT" > Wed Jun 1 14:00:00 UTC 2005 > > # date -d "1970-01-01 1117634400 sec GMT" > Wed Jun 1 16:00:00 CEST 2005 > > > > # date -u -d "1970-01-01 1117634400 sec CEST" > Wed Jun 1 12:00:00 UTC 2005 > # date -u -d "1970-01-01 1117634400 sec CET" > Wed Jun 1 13:00:00 UTC 2005 > Two different times... > > # date -u -d "1970-01-01 1117634400 sec MET" > Wed Jun 1 13:00:00 UTC 2005 > # date -u -d "1970-01-01 1117634400 sec MEST" > Wed Jun 1 12:00:00 UTC 2005 > Two different times... > > > # date -d "1970-01-01 1117634400 sec CET" > Wed Jun 1 15:00:00 CEST 2005 > # date -d "1970-01-01 1117634400 sec CEST" > Wed Jun 1 15:00:00 CEST 2005 > One time ... > > # date -u -d "1970-01-01 1117634400 sec" +"%D %T %z %Z" > 06/01/05 14:00:00 +0000 UTC > # date -u -d "1970-01-01 UTC 1117634400 sec" +"%D %T %z %Z" > 06/01/05 14:00:00 +0000 UTC > # date -u -d "1970-01-01 MET 1117634400 sec" +"%D %T %z %Z" > 06/01/05 13:00:00 +0000 UTC > # date -u -d "1970-01-01 MEST 1117634400 sec" +"%D %T %z %Z" > 06/01/05 12:00:00 +0000 UTC > # date -d "1970-01-01 1117634400 sec" +"%D %T %z %Z" > 06/01/05 15:00:00 +0200 CEST > # date -d "1970-01-01 UTC 1117634400 sec" +"%D %T %z %Z" > 06/01/05 16:00:00 +0200 CEST > > # date -d "1970-01-01 MET 1117634400 sec" +"%D %T %z %Z" > 06/01/05 15:00:00 +0200 CEST > # date -d "1970-01-01 MEST 1117634400 sec" +"%D %T %z %Z" > 06/01/05 14:00:00 +0200 CEST > > # date -d "1970-01-01 1117634400 sec CEST" +"%D %T %z %Z" > 06/01/05 15:00:00 +0200 CEST > # date -d "1970-01-01 1117634400 sec CET" +"%D %T %z %Z" > 06/01/05 15:00:00 +0200 CEST > > > That looks like "MEST" is defined other than "CEST"? -- NH
