Recently I began to work with google-rfc-2445 library and met a same problem as SO user Art Zaborskiy here: Start date returns in some cases when using google-rfc-2445 (iCalendar)
After SO user oberron pointed to specification in him answer here, where being said that:
[...] The COUNT rule part defines the number of occurrences at which
to range-bound the recurrence. The "DTSTART" property value, if
specified, counts as the first occurrence. [...]
I was sure that my issue is over, and it isn't issue but feature. I thought so till I found rrule.js libary here, in its demo page it returns exactly 10 occurrences without DTSTART occurrence, while same RRULE String in google-rfc-2445 return 11 occurrences.
The RRULE String is following: FREQ=WEEKLY;COUNT=10;BYDAY=MO;DTSTART=20150301
Now I totally confused, should or shouldn't DTSTART occurrence be in a list of all occurrences?
Thank you for your clarification.
Related
We just added Swiftlint to our project and we want to follow all the rules but I'm not sure what's meant by 'type_body_length' warning. I'm not a native english speaker so I find it a bit confusing.
There is a rule for file length aswell so how do they differ? What falls under this definition?
type_body_length violation means that the class has too many lines in it. I dont think it counts extensions, comments or whitespace
Type name should only contain alphanumeric characters, start with an uppercase character and span between 3 and 40 characters in length.
The rules documentation linked here and above also gives examples of what would and wouldn't be accepted (Triggering & Non Triggering). - Edit suggested by #GoodSp33d, thanks
So as in the title, I'm trying to format a date in dd_mm_yy format using time.Now().Format("02_01_2006") as shown in this playground session:
http://play.golang.org/p/alAj-OcRZt
First problem, dd_mm_yyyy isn't an acceptable format, only dd_mm_yy is, which is fine I can manipulate the returned string myself.
The problem I have for you is to help me figure out what Go is even trying to do with this input.
You should notice the result you get is:
10_1110009
A good few thousand years off and it's lost the underscore which it only does it for _2. Does this character sequence represent something special here?
Replacing the last underscore with a hyphen or space returns a valid result. dd_mm_yy works fine. Just this particular case seems to completely fly off the handle.
On my local machine (Go playground is on a specific date) the result for today (the 5th) is:
05_01 5016
Which is equally strange, if not moreso as it's substituted in a space which seems to be an ANSIC thing.
This is very likely due to the following bug: https://github.com/golang/go/issues/11334
This has been fixed in Go 1.6beta1
Found an issue from their github:
https://github.com/golang/go/issues/11334
Basically _2 is taking the 2 as the day value from the reference time and then trying to parse the rest (006) which it doesn't recognise so it all goes wrong from there.
http://en.wikipedia.org/wiki/ISO_8601#Durations
It's not clear what the most correct representation of zero in ISO 8601 durations is.
Possible candidates:
PT0S
This site:
http://www.ostyn.com/standards/scorm/samples/ISOTimeForSCORM.htm
says
PT0H0M0S
Or probably the simplest is
P
But what is most correct? Is there a canonical zero duration representation?
The single letter "P" is certainly wrong because at least one duration element must be present.
The SCORM-specification requires "PT0H0M0S" only because of backwards compatibility with earlier SCORM-Versions, not because ISO mandates it. Citation from the link you have given:
the SCORM 2004 1.3.1 conformance test suite was coded to require the PT0H0M0S format for the initial zero value of the total attempt
time; using that format is therefore recommended where compatibility
with early implementations of SCORM 2004 is required.
So if you don't use SCORM then the expression "PT0S" is completely sufficient. However, I don't remember any location in the original ISO-8601-paper where they have specified how a zero duration has to look like. On the contrary, ISO-8601 also describes alternative duration formats like "P0000-00-00T00:00".
There is not only one single canonical representation if we interprete the word "canonical" as "conform with ISO-8601".
Update (after looking in the original ISO-paper):
ISO-8601 mandates at least one element for a zero duration (4.4.3.2.c - page 21):
If the number of years, months, days, hours, minutes or seconds in any
of these expressions equals zero, the number and the corresponding
designator may be absent; however, at least one number and its
designator shall be present.
Paragraph 4.4.3.3 says:
The complete representation of the expression for duration in the
alternative format is as follows:
Basic format: PYYYYMMDDThhmmss or PYYYYDDDThhmmss
Extended format: PYYYY-MM-DDThh:mm:ss or PYYYY-DDDThh:mm:ss
Keep also in mind that not every software is capable of supporting all format variations.
Is there a way to control the order in which files appear in a gist? They don't seem to be alphabetical or chronological. I'd like to have a README.md appear as the first file in a multi-file gist, but no amount of "deleting" a file and re-adding it seems to change anything.
Is there an order to these files that I'm not seeing, or does GitHub maintain an internal filetype priority list?
Since at least 2018, the order is alphabetical, with periods and numbers coming before letters.
That is, as mentioned in Andrew D.Bond's answer:
$
. (dot)
Numbers
Leading space (although the space doesn't appear after saving, the sort order is still updated)
(although bis, in Sept. 2020, IvanaGyro adds in the comments leading spaces will not affect the order any more)
_ (underscore)
Letters (case insensitive)
Around 2013-2014 a different order was used. See Andrew D. Bond's answer for more.
They are ordered automatically by name, following the ASCII table.
Unfortunatly, right now, it is not possible to order them by dragging, but there is a trick. You can control the order by adding one or more spaces before the name. The space will not be shown after editing, but the order will change.
E.g: lets say we have 3 files with the automatic order:
AFile.java
Readme.md
SomeFile.txt
We can invert the order by putting spaces like this:
(space)(space)SomeFile.txt
(space)Readme.md
AFile.txt
Updating my answer from an earlier year with additional testing I did just now:
Github automatically sorts files in a gist according to:
#
$
. (period)
Numbers
_ (underscore)
Letters (case insensitive)
Leading spaces are dropped.
If additional characters' sort order is discovered, feel free to edit this answer.
(Added this answer because even after I improved another answer to this question last year, I still couldn't find the sort order of special characters anywhere.)
As mentioned by #VonC in his answer, the order is asciibetical. Quick solution would be to prefix all files with numbers indicating the order in which you wish the files to appear, example 0_, 1_, 2_, ... 9_. Note, this solution will not work beyond 9 files as 10_ will appear before 2_. In that case, two digits need to be used 00_, 01_, 02_, ..., 09_, 10_, 11_, ... This can be generalized to any number of digits in the number of files. Although, it seems less likely, to me, that more more than 10 files to be shared in a gist.
In my app before I send a string off I need to work out if the text entered in the textbox is a UK Postcode. I don't have the regex ability to work that out for myself and after searching around I can't seem to work it out! Just wondered if anyone has done a similar thing in the past?
Or if anyone can point me in the right direction I would be most appreciative!
Tom
Wikipedia has a good section about this. Basically the answer depends on what sort of pathological cases you want to handle. For example:
An alternative short regular expression from BS7666 Schema is:
[A-Z]{1,2}[0-9R][0-9A-Z]? [0-9][ABD-HJLNP-UW-Z]{2}
The above expressions fail to exclude many non-existent area codes (such as A, AA, Z and ZY).
Basically, read that section of Wikipedia thoroughly and decide what you need.
for post codes without spaces (e.g. SE19QZ) I use: (its not failed me yet ;-) )
^([Gg][Ii][Rr] 0[Aa]{2})|((([A-Za-z][0-9]{1,2})|(([A-Za-z][A-Ha-hJ-Yj-y][0-9]{1,2})|(([A-Za-z][0-9][A-Za-z])|([A-Za-z][A-Ha-hJ-Yj-y][0-9]?[A-Za-z])))) [0-9][A-Za-z]{2})
if spaces (e.g. SE1 9QZ) , then:
^([Gg][Ii][Rr] 0[Aa]{2})|((([A-Za-z][0-9]{1,2})|(([A-Za-z][A-Ha-hJ-Yj-y][0-9]{1,2})|(([A-Za-z][0-9][A-Za-z])|([A-Za-z][A-Ha-hJ-Yj-y][0-9]?[A-Za-z])))) {0,1}[0-9][A-Za-z]{2})$
You can match most post codes with this regex:
/[A-Z]{1,2}[0-9]{1,2}\s?[0-9]{1,2}[A-Z]{1,2}/i
Which means... A-Z one or two times ({1,2}) followed by 0-9 1 or two times, followed by a space \s optionally ? followed by 0-9 one or two times, followed by A-Z one or two times.
This will match some false positives, as I can make up post codes like ZZ00 00ZZ, but to accurately match all post codes, the only way is to buy post code data from the post office - which is quite expensive. You could also download free post code databases, but they do not have 100% coverage.
Hope this helps.
Wikipedia has some regexes for UK Postcodes: http://en.wikipedia.org/wiki/Postcodes_in_the_United_Kingdom#Validation