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.
Related
I'm working with nlpcraft to build a parsing system for scheduling. Users are asked when they will be doing certain activities and they can respond with relative or absolute dates, such as "tuesday and wednesday" or "not until 8/15".
While nlpcraft has very nice relative date parsing, near as I can tell it always parses dates relative to the current system time in UTC. Not only does this complicate testing (because the input is relative while the output is absolute), it means that if the server does not parse the input close to the time the user wrote it, relative dates may be parsed incorrectly. For example, if the user says "tomorrow" at 11PM on a Sunday, but the server doesn't parse it until 5AM on Monday, it might result in Tuesday instead of Monday.
I looked into NCDateEnricher where this all seems to happen and then parsing routine computes a base time as the current system time. I didn't see a way to override this with a config variable or request parameter -- am I missing something?
UTC time server on server-side allows users to easily convert times to local timezone. It's the simplest way to support different timezone users with one server.
If you aren't satisfied with nlpcart provided date NER, you can look at date/time NERS from opennlp/stanford/spacy/google, which can be simply used with nlpcraft system (https://nlpcraft.incubator.apache.org/integrations.html)
Is there a way to assign a score for mail sent between certain hours. I find a lot of spam is sent in the middle of the night so would like to give anything between say 2am and 5am a score of 2 or 3.
You can use SpamAssassin to penalize mail received within certain hours, but it's messy.
Before we start, verify that SA's primary defenses are properly set up:
DNS Blocklists, including DNSBLs & URIBLs, are a necessity; set them up before all else
Bayes in SpamAssassin is another must-have, though it requires training
Use Razor for fuzzy matching (see also Installing Razor) if the license works for you.
If that's insufficient, then you can address the sort of issue you're keying on. Try:
The RelayCountry plugin to penalize countries you never converse with
The TextCat plugin to discriminate against the languages you never converse in
If all that doesn't help enough, then (and only then) you can consider what you proposed. Read on.
Don't forget about time zones. You can't use the Date header for this reason. This type of rule is not safe for deployments that have conversations that span too many time zones, and you must ensure the MX record servers are all consistent and on the same time zone. Be aware that daylight savings (aka “summer time”) can be annoying here.
Identify a relay that your receiving infrastructure adds but is added before SpamAssassin runs (so SA can see it). This will manifest as a Received header near the top of your email. Again, make sure it's actually visible to SpamAssassin; the Received header added by your IMAP server will not be visible.
It is possible that you have SpamAssassin configured to run before any internal relay is stamped into the message. If this is the case, do not proceed further as you cannot reliably determine the local time.
Okay, all caveats aside, here's an example Received header:
Received: from external-host.example.com
(external-host.example.com [198.51.100.25])
by mx.mydomain with ESMTPS id ABC123DEF456;
Fri, 13 Mar 2020 12:34:56 -0400 (EDT)
This must be a header one of your systems adds or else it could have a different time zone, clock skew, or even a forged timestamp.
Match that in a rule that clearly denotes you as the author (by convention, start it with your initials):
header CL_RCVD_WEE_HOURS Received =~ /\sby\smx\.mydomain\swith\s[^:]{9,64}+:(?<=[0 ][2-4]:)[0-9:]{5}\s-0[45]00\s/
describe CL_RCVD_WEE_HOURS Received by our mx.mydomain relay between 2a and 5a EST/EDT
score CL_RCVD_WEE_HOURS 0.500
A walk through that regex (see also an interactive explanation at Regex101):
First, you need to verify that it's your relay, matched by name: by mx.mydomain with
Then, skip ahead 9-64 non-colon characters (quickly, with no backtracking, thus the + sign). You'll need to verify your server doesn't have any colons here
The real meat is in a look-behind (since we actually skipped over the hour for speed purposes), which seeks the leading zero (or else a space) and then the 2, 3, or 4 (not 5 since we don't want to match a time like 05:59:59)
Finally, there's a sanity check to ensure we're looking at the right time zone. I assumed you're in the US on the east coast, which is -0400 or -0500 depending on whether daylight savings is in effect
So you'll need to change the server name, review whether the colon trick works with your relay, and possibly adjust the time zone regex.
I also gave this a lower score than you desired. Start low and slowly raise it as needed. 3.000 is a really high value.
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.
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".)