I want to know that is there any command which can provide time without DST if DST is applicable in the zone.
I have searched lot in google but not getting proper answer. I think there should be simple solution to get it.
Below is one link on stackoverflow.com but I am not getting
https://unix.stackexchange.com/questions/123493/disable-daylight-saving-time-in-debian-linux
For example:
current time in Newyork is
date
Wed Mar 23 04:51:54 EDT 2016
As per DST-free timezone definitions provided which just define the GMT-offset, called Etc/GMT±X:
TZ=Etc/GMT-1 date
Wed Mar 23 10:13:09 GMT-1 2016
Whereas DST is 1 hour forward on March 23 i.e. it should be Wed, Mar 23, 2016, 4:13 AM
Please anyone provide help.
U.S. Eastern time is often represented by the time zone name "America/New_York" or "US/Eastern". Equivalently, there is the "Posix" time zone name "EST5EDT". The essential fact here is that this zone is nominally 5 hours off of UTC (or 4 hours when daylight saving time is in effect).
There are also some DST-free zone names of the form "UTC-4" and "UTC+5".
So if you say
export TZ="UTC+5"
date
You'll see the date in the equivalent of U.S. Eastern Standard Time, without a DST correction.
(This is essentially what the high-rated answer at https://unix.stackexchange.com/questions/123493/disable-daylight-saving-time-in-debian-linux was trying to tell you, I think.)
If you wanted to take an arbitrary time zone name and construct from it an equivalent DST-free zone name, that'd be pretty tricky.
Related
Mexico City's DST (Daylight Saving Time) ended on OCT28 2018 at 3:00 AM local time, that is the exact moment when clocks where moved backward one hour in time to start at 2:00 again.
When creating the following aware datetime:
>>>mex = pytz.timezone('America/Mexico_City')
>>>mex_dt = mex.localize(datetime(2018,10,28,1,30))
I get this result:
>>>print(mex_dt)
2018-10-28 01:30:00-06:00
While the correct result should be:
2018-10-28 01:30:00-05:00
because the created 01:30AM time still belongs to DST and should have an offset of -05:00. It seems like pytz supposes all countries move their clocks backwards at 2:00, but this is not the case in Mexico, where this happens at 3:00
Does anybody know how I can correct for this? suggestions?
I see you asked the same question on the IANA time zone mailing list.
As Paul Eggert replied there, your information appears to be incorrect. Mexico's official time policy indeed sets the time of transition at 2:00. If you have information to the contrary, please share your source.
You can also see this change visualized here, or read about time in Mexico on Wikipedia.
If I define a specific time, how to get other local's time?
I use node.js and I know module (date-utils, moment-timezone). I will use some parameters (e.g. year, month, day, hour, minutes) and I want to get other country's time.
For example my server's local is America and I use a parameter (not real time specific time I want, and its my local's time) to server.
If I want to get Korean local time, what should I do?
If I want Korean's time 2015 07 07 11 11 and I will have 2015 07 07 11 11
how to get the Korean time from server?
I have the following small php snippet running on a gentoo Linux (php version 5.2.10-pl0-gentoo):
#!/usr/bin/php5
<?
class TestDaemon {
public function __construct(){
while (TRUE){
unset($aDate);
exec("date", $aDate);
print("date(\"d.m.y H:i:s\") yields: ".date("d.m.y H:i:s")." while 'date' yields $aDate[0].\n");
sleep(1);
}
}
}
$oDaemon = new TestDaemon();
?>
And the output produced is as follows:
date("d.m.y H:i:s") yields: 27.03.14 07:05:27 while 'date' yields Thu Mar 27 07:05:03 UTC 2014.
date("d.m.y H:i:s") yields: 27.03.14 07:05:28 while 'date' yields Thu Mar 27 07:05:04 UTC 2014.
date("d.m.y H:i:s") yields: 27.03.14 07:05:29 while 'date' yields Thu Mar 27 07:05:05 UTC 2014.
date("d.m.y H:i:s") yields: 27.03.14 07:05:30 while 'date' yields Thu Mar 27 07:05:06 UTC 2014.
date("d.m.y H:i:s") yields: 27.03.14 07:05:32 while 'date' yields Thu Mar 27 07:05:07 UTC 2014.
date("d.m.y H:i:s") yields: 27.03.14 07:05:33 while 'date' yields Thu Mar 27 07:05:09 UTC 2014.
date("d.m.y H:i:s") yields: 27.03.14 07:05:34 while 'date' yields Thu Mar 27 07:05:10 UTC 2014.
date("d.m.y H:i:s") yields: 27.03.14 07:05:35 while 'date' yields Thu Mar 27 07:05:11 UTC 2014.
As you can see the times are off by approx. 24 seconds. On a different machine (same OS, same version of PHP) I do not see such an offset.
What is the reason for this offset? Does this come from leap second differences? Then which system gives the correct time? Why does php not use the Linux system time instead?
Also, can this time offset be a source of problems when working with the mysql database on the same system?
This looks like the shell running /bin/date is configured to use the "right" timezones and php is configured to use the POSIX-conformant timezones. The difference now should be 25 seconds, but if the tz data is over two years old then it would be 24 seconds. For a picture of why visit http://www.ucolick.org/~sla/leapsecs/amsci.html and see the second plot. The "right" zones follow the green line. The POSIX zones are required to stop the system clock on every leap second, so they follow the descending staircase of the blue line. [edit to be sure which was using which method]
Why the offset I don't know, but it seems that php date() uses time() function to get a timestamp. time() is defined like this:
Returns the current time measured in the number of seconds since the Unix Epoch (January 1 1970 00:00:00 GMT).
it never says in documentation that it uses System time.
According to this SO post the function time() uses the date.timezone set in php.ini or date_default_timezone_set().
So if your system uses a different time zone than your php.ini it could explain the difference because php seems to use its own time.
He also propose the following solution to get the real system time if they are not the same:
I'm going to give you a solution that works for Linux, I don't know for Windows. In Linux the system timezone is set in /etc/timezone.
Now, this is normally outside my allowed open_basedir setting, but you can add :/etc/timezone to your list to be able to read the file.
Then, on top of the scripts, that want to get the system time, you can call a library function that sets the script timezone to the system timezone. I suppose that this function is part of a class, so I use static:
static function setSystemTz() {
$systemTz = trim(file_get_contents("/etc/timezone"));
if ($systemTz == 'Etc/UTC') $systemTz = 'UTC';
date_default_timezone_set($systemTz);
}
To make the matter worse in PHP 5.3.3 'Etc/UTC' is not recognized, while 'UTC' is, so I had to add an if to fix that.
Not really answering your question but there are many different types of time variable on a typical Linux system:
The internal time of the harware clock (aka RTC or BIOS time), if you have one. This keeps the time when the system is offline, this may be fake and return bad values on a virtual machine, or you might not even have one. See hwclock
The amount of time that has passed since the kernel was started. (cat /proc/uptime)
The external time as provided by an NTP server via ntpd.
The innacuracy of the realtime clock / time source, how much it drifts over time in parts per million between samples. This is set by calls to the kernel. On a system with NTP it will be saved to your drift file (/var/lib/ntp/drift/ntp.drift or similar) and the system's time will be smoothly adjusted rather than have time jumps in your logs.
The number of miliseconds since 1st of January 1970. See date +%s
Your timezone, set in /etc/localtime, see zdump /etc/localtime
The current system time, calculated using all of the above plus rules for timezone, leap year, leap second and so on. See date
If I had to guess, I'd say that NTP is slowly adjusting your system time to compensate for your skewed realtime clock while PHP bypasses this and snags it from somewhere else.
I have a situation where the relative time is more important to a user than an absolute time. So it's more important to be able to quickly say "event happened 5 days and 5 hours ago" than "event happened at 1 PM CDT and it's 5 PM CST 5 days later now."
We store our dates in UTC and convert to display for the user:
pDateTime = DateTime.SpecifyKind(pDateTime, DateTimeKind.Utc);
DateTimeZone dateTimeZone = DateTimeZoneProviders.Tzdb[pCurrentUser.PreferredTimezone];
return Instant.FromDateTimeUtc(pDateTime).InZone(dateTimeZone).ToString("HH':'mm':'ss' 'MM'/'dd'/'yy' 'x", CultureInfo.InvariantCulture);
We'll be using NodaTime 1.2 when it's fully out and just used vanilla ToString before.
However, times using this pattern end up using the daylight status of the time as opposed to the current daylight status. This means that times look something like: 16:15:32 10/25/13 CDT even though we have now transitioned to CST.
It is an absolute measure of the time. This forces the user to do the logic: "How long ago was that? Is it daylight saving time now? If so, the difference is x. If not, I have to add or subtract an hour? That makes the difference y."
Meanwhile, a relative measure of the time would display 15:15:32 10/25/13 CST in the absence of DST. This forces the user to do no conversions and allows them to compute what that time means in context much easier.
In a display that has numerous dates, it can get tricky to do the absolute time logic over the entire set. Doing it once is tricky to get right. However, a friendly relative string like "posted 5 hours ago" also forces them to resolve both the date and time themselves - that information is still important.
A compromise might be to do the posted blank hours/minutes ago for the first 24 hours or to include both the friendly string and absolute time - these are both patterns I've seen done.
But ignoring those, is there a way in NodaTime to imbue a time with a specific daylight status in order to get times displaying in a relative context?
However, times using this pattern end up using the daylight status of the time as opposed to the current daylight status. This means that times look something like: 16:15:32 10/25/13 CDT even though we have now transitioned to CST.
Yes, and it should. Displaying a date/time with CST despite that date/time occurring in CDT would be very odd, IMO.
So it's more important to be able to quickly say "event happened 5 days and 5 hours ago" than "event happened at 1 PM CDT and it's 5 PM CST 5 days later now."
In that case you shouldn't be displaying a date/time at all, in my view. Convert both ZonedDateTime values to Instant, take the Duration between them, and then you can see that it's 5 days and 5 hours ago. (I can't remember how much help we provide with that - you may need to manually take the number of ticks and divide by NodaConstants.TicksPerStandardDay etc. Look at DurationPattern to see if it helps though.)
Alternatively, if you really want to display a date and time, but still easily be able to extract the difference between them mentally, two options suggest themselves:
Use OffsetDateTime instead; there you could force the offsets to be the same, although I still think it would be odd to display an offset which wasn't actually the current offset in the zone you were observing the time in. Or you could just display the relevant offset at the time, so -5 for CST and -4 for CDT.
Just display everything in UTC, so that daylight saving transitions are irrelevant.
Note that you can't get months between the two ZonedDateTime values, as we're dealing with an elapsed time (a duration) rather than calendar-logical arithmetic (a period).
I am hoping to get a quick answer to one question about NodaTime before downloading it. So far, I am reading about NodaTime and its API and it seems very carefully thought out.
I hope it might help eliminate some of the chaos I've been encountering in an application that has a database back-end, a desktop client with a database provider, and a web client that must run on the major browsers. The support for ISO 8601 on DateTime and Time varies greatly on the various database, database provider, and web platforms. Internet Explorer, for example, follows ISO 8601 but SQL Server does not; web UI timepickers do not because Chrome does not.
QUESTION: In NodaTime, is 24:00 a valid Time value? Is 24 a valid argument for the hours parameter of its Time constructors?
BACKGROUND: ISO 8601 allows for two representations of midnight: 00:00 for "midnight this morning" and 24:00 for "midnight tonight". When the DateTime object is on the time-line, a date whose time element has 24:00 coincides with the next day at 00:00. They are the same time-line instant with two different representations, both representations valid per ISO.
A Time-only value is detached from the time-line. A time of 00:00 occurs at the beginning of the detached 24-hour day and a Time-only value of 24:00 is 24 hours after 00:00. A Time type should accept 24 in the hour. When 24 is the hour the maximum value for seconds and milliseconds and ticks is 0 (unless modulo arithmetic is involved and the time rolls over, so that 24:01 is 00:01 -- but ISO has nothing to say about this implementation detail, IIRC).
We accept 24:00 when parsing a LocalDateTime, but not 24:01.
This was issue 153, implemented in revision f7ac0365d8ca.
Unfortunately this was after the 1.0 release, so you'll either need to grab the current code, or wait for 1.1 to be released (hopefully soon).
We don't currently accept it when parsing just a LocalTime. If you want that, please log a feature request - we'd probably look at it for 1.2 (which will have a lot of text features), although I'm not sure what the representation would look like. (LocalTime itself doesn't support the idea of "end-of-day midnight".)