I am doing some "software archaeology" on python-dateutil to fully document (and tighten up) the formats accepted by dateutil.tz.tzstr, and I have come across a strange timezone format that is obviously intended to be explicitly supported (link goes to the code):
# GMT0BST,3,0,30,3600,10,0,26,7200[,3600]
Just reading the code, I've figured out how it works. It starts out like a TZ environment variable:
GMT: Standard time abbreviation
0: Standard offset (in hours)
BST: DST abbreviation
Then the rest is a comma-delimited list, broken into two parts:
3,0,30,3600: DST->STD transition time specifier - month, week of month, day of week, seconds after midnight that the transition happens (note that when "week of month" is 0, the number following is actually the day of the month)
10,0,26,7200: STD->DST transition time specifier - same as above
[,3600]: If specified, this says how big the offset is during DST (default is 1 hour)
The GNU TZ variable equivalent to this string is GMT0BST,J89/1,J299/2:
>>> from dateutil import tz
>>> tz1 = tz.tzstr('GMT0BST,3,0,30,3600,10,0,26,7200')
>>> tz2 = tz.tzstr('GMT0BST,J89/1,J299/2')
>>> tz1 == tz2
True
Is this a standard timezone format somewhere, or just something that one of the earlier maintainers of dateutil added? It seems somewhat strange to add a custom time zone format that expresses exactly the same thing a GNU TZ variable does, but I only ever see "IANA database" and "POSIX TZ variable" as formats when searching for time zone rules.
No, that's not a standard format of any kind (AFAIK). Must be something internal to dateutil.
Note that this appears to be for Europe/London, and the correct POSIX string (for current years) would be GMT0BST,M3.3.0/1,M10.5.0
Related
I am seeing error the input "06/09/22 02:14 CDT" can't be parsed as format MM/dd/yy HH:mm ZZZZ` when trying to get luxon date time from string.
DateTime.fromFormat("06/09/22 02:14 CDT","MM/dd/yy HH:mm ZZZZ")
Not sure what is the valid format I need to use when there is time zone in date string.
Thanks.
Issue is that you input contains CDT that is not recognized by Luxon since ZZZZ is not a valid token as explained in the Parsing -> Limitations section of the docs:
Not every token supported by DateTime#toFormat is supported in the parser. For example, there's no ZZZZ or ZZZZZ tokens. This is for a few reasons:
Luxon relies on natively-available functionality that only provides the mapping in one direction. We can ask what the named offset is and get "Eastern Standard Time" but not ask what "Eastern Standard Time" is most likely to mean.
Some things are ambiguous. There are several Eastern Standard Times in different countries and Luxon has no way to know which one you mean without additional information (such as that the zone is America/New_York) that would make EST superfluous anyway. Similarly, the single-letter month and weekday formats (EEEEE) that are useful in displaying calendars graphically can't be parsed because of their ambiguity.
You can add fixed string 'CDT' in your format or remove it completely from your input. You can use zone option (America/New_York in the example above, or America/Chicago in your use case) of DateTime#toFormat to take into account timezone offset.
Example:
const DateTime = luxon.DateTime;
const dt1 = DateTime.fromFormat("06/09/22 02:14 CDT","MM/dd/yy HH:mm 'CDT'", {zone: 'America/Chicago'})
const dt2 = DateTime.fromFormat("06/09/22 02:14", "MM/dd/yy HH:mm", {zone: 'America/Chicago'})
console.log(dt1.toISO());
console.log(dt2.toISO());
<script src="https://cdn.jsdelivr.net/npm/luxon#2.4.0/build/global/luxon.min.js"></script>
This question already has answers here:
How to make a timezone aware datetime object
(15 answers)
Closed 6 years ago.
I've got a datetime which has no timezone information. I'm now getting the timezone info and would like to add the timezone into the existed datetime instance, how can I do?
d = datetime.datetime.now()
tz = pytz.timezone('Asia/Taipei')
How to add the timezone info tz into datetime a
Use tz.localize(d) to localize the instance. From the documentation:
The first is to use the localize() method provided by the pytz library. This is used to localize a naive datetime (datetime with no timezone information):
>>> loc_dt = eastern.localize(datetime(2002, 10, 27, 6, 0, 0))
>>> print(loc_dt.strftime(fmt))
2002-10-27 06:00:00 EST-0500
If you don't use tz.localize(), but use datetime.replace(), chances are that a historical offset is used instead; tz.localize() will pick the right offset in effect for the given date. The US Eastern timezone DST start and end dates have changed over time, for example.
When you try to localize a datetime value that is ambiguous because it straddles the transition period from summer to winter time or vice-versa, the timezone will be consulted to see if the resulting datetime object should have .dst() return True or False. You can override the default for the timezone with the is_dst keyword argument for .localize():
dt = tz.localize(naive, is_dst=True)
or even switch off the choice altogether by setting is_dst=None. In that case, or in the rare cases there is no default set for a timezone, an ambiguous datetime value would lead to a AmbiguousTimeError exception being raised. The is_dst flag is only consulted for datetime values that are ambiguous and is ignored otherwise.
To go back the other way, turn a timezone-aware object back to a naive object, use .replace(tzinfo=None):
naivedt = awaredt.replace(tzinfo=None)
If you know that your original datetime was "measured" in the time zone you are trying to add to it, you could (but probably shouldn't) use replace rather than localize.
# d = datetime.datetime.now()
# tz = pytz.timezone('Asia/Taipei')
d = d.replace(tzinfo=tz)
I can imagine 2 times when this might make sense (the second one happened to me):
Your server locale is set to the incorrect time zone and you are trying to correct a datetime instance by making it aware of this incorrect timezone (and presumably later localizing it to the "correct" time zone so the values of now() match up to other times you are comparing it to (your watch, perhaps)
You want to "tag" a time instance (NOT a datetime) with a time zone (tzinfo) attribute so that attribute can be used later to form a full datetime instance.
I've found a couple of existing StackoverFlow questions on this but nothing very definite.
I have a local datetime. I want this in UTC. my local datetime does not have a 'Z' at the end or any offset information.
I first tried:
moment(mylocaldatetime).toISOString() #works fine because this method always returns time in UTC
But for consistency with other code I didn't want to use to ISOString() so I did this:
moment(mylocaldatetime).utc().format()
This seems to work fine. If the browser running this code is in UTC + 1 I get a datetime one hour less than mylocaldatetime (with an offset string if I specify that in the format). I.e. it has treated mylocaldatetime as a local time, taken account of my current time zone, and given me my local time as UTC.
However. This appears to contradict the moment.js docs which are pretty clear that:
If you want to parse or display a moment in UTC, you can use moment.utc() instead of moment(). - Notice the 'parse'.
and
Moment normally interprets input times as local times (or UTC times if moment.utc() is used).
If these doc comments were true this line:
moment(mylocaldatetime).utc().format()
should treat mylocaldatetime as if it were utc and then output this datetime in utc - no difference. No conversion. But that is not what I get.
Maybe what this line moment(mylocaldatetime).utc().format() is saying is:
create a moment object in local mode with mylocaldatetime. Then put the moment object into utc mode. So now when we format for display we output as utc. IF this is the case I think the docs could be made clearer.
Does the below 2 syntaxes are same,
moment(1456261200367, 'H:mm:ss.SSS').utc().valueOf() //1456343786120
moment(1456261200367 +0000, 'H:mm:ss.SSS Z').valueOf() //1456325786120
but as you could see if both of them coverts the given value to UTC mode then why there is a difference in the output?
Also I would like to know how a.valueOf() and b.valueOf() are same, when a.format() and b.format() are different, because moment() (moment parses and displays in local time) is different from moment.utc() (displays a moment in UTC mode)
var a = moment();
var b = moment.utc();
a.format();
b.format();
a.valueOf();
b.valueOf();
In the first part, you're using it incorrectly. You've passed numeric input which would normally be interpreted as a unix timestamp, but then you've supplied a string-based format string so the number is converted to a string. The format string here is telling moment how the input is specified, but it doesn't match what you're actually parsing.
This doesn't error though, because by default moment's parser is in "forgiving" mode. You can read more about this in the docs.
The correct way to pass a timestamp into moment is with one of these:
moment(1456261200367)
moment(1456261200367).utc()
moment.utc(1456261200367)
The last two are equivalent, but the moment.utc(timestamp) form is prefered.
With any of those, all three will have the same .valueOf(), which is just the timestamp you started with. The difference is in the mode that the moment object is in. The first one is in local mode, reflecting the time zone of the computer where it's running, while the other two are in UTC mode.
This is evident when you format the output using the format function, as with other many other functions. I believe that answers your second question as well.
I'm working on a program (we'll call this the PostProcessor) that applies some post-processing to the output of another, closed-source program (we'll call this the Original program. Part of the post-processing involves re-calculating a DateTime value and outputting it in the same format as the original.
For example, the Original may output:
03 : 15 : 30 [h:min:s]
The PostProcessor calculates that the actual time should be 4 hours, 20 minutes and 10 seconds and should output:
04 : 20 : 10 [h:min:s]
The "nice" thing is, despite being mostly a black-box, Original program has some configuration settings. Buried deep within these settings is a string value TimeOutputFormat, which PostProcessor can read.
In the above examples, the TimeOutputFormat string was:
%#H : %M : %S [h:min:s]
Another valid format string I've encountered is:
%q2 min
Which outputs the total minutes to 2 decimal places.
From fiddling around, I've also found the %c format string, which outputs in the form:
1/1/1970 03:15:30 AM
which confirms that the Original program is storing these DateTime values in some form of Unix time object.
What I would like to find out is what formatting system is being used, so I can implement it in my PostProcessor. I'm hoping it's a somewhat standard format since I don't have any documentation. The black-box Original program uses a mixture of Visual C++, .NET, and Python modules (and possibly other technologies I'm not aware of).
Here's a catalog of what I've found so far.
# before the letter (i.e. %#d) pads the value with leading 0's
# removes padding from a value %d -> 01 but %#d -> 1
a digit after the letter (i.e. `%d3') displays decimal digits (if the value has them)
Known formatting strings (from trial/error)
%H - Hour component (not total hours, just the hour component)
%M - Minute component
%S - Second component
%a - Day of week (three letter abbrev.)
%b - Month (three letter abbrev.)
%c - Full date (m/d/yyyy HH:MM AM/PM)
%d - Not sure (outputs "01") (guessing day?)
%e-i Not defined
%j - Not sure (outputs "001") (guessing day out of 365?)
%k-l Not defined
%m - Not sure (outputs "01") (guessing month?)
%q - Total minutes
%p - AM/PM
If anyone can identify this formatting system, I'd greatly appreciate it. I'm going to continue to catalog it for my own use, but it would be nice to have some original documentation if it happens to be a publicly available (and hopefully well-documented) system.