Can we change the expected time stamp format?

[ackermag]

Currently these are required for validation:
mm/dd/yyyy hh:mm:ss or mm/dd/yyyy hh:mm or mm/dd/yyyy hh or mm/dd/yyyy or mm/yyyy or yyyy.

None of these are compatible with Excel, requiring individual curation. Please...or should I just ignore the warnings ( in the template the year is yyyy but it is shortened).
804_20160706-235613.txt

[antgonza]

Looking at the defaults in Excel, see below, I can add:
mm/dd/yy hh:mm:ss
mm/dd/yy hh:mm
mm/dd/yy hh
mm/dd/yy
mm/yy
m/dd/yy hh:mm:ss
m/dd/yy hh:mm
m/dd/yy hh
m/dd/yy
m/yy

Sounds good?

[antgonza]

friendly ping to @ackermag

[ackermag]

Sounds good... to me.

[antgonza]

Still need to fix it! Will issue PR soon. :)

[ackermag]

From MIMARKS_v4.xls
"The time of sampling, either as an instance (single point in time) or interval. In case no exact time is available, the date/time can be right truncated i.e. all of these are valid times: 2008-01-23T19:23:10+00:00; 2008-01-23T19:23:10; 2008-01-23; 2008-01; 2008; Except: 2008-01; 2008 all are ISO8601 compliant"
Although most of our users (I believe) are US based and conform to mm/dd/yyyy where Excel trims to ((m)m/(d)d-yy), confusion arises with non-US users. (As a general rule, users rarely conform to a suggested format.) I am open to suggestion again, but suggest we use the recommendation but not require '2008-01-23T19:23:10+00:00' or '2008-01-23T19:23:10' because no-one will conform to that.

Suggest:
YYYY-MM-DD HH:MM; YYYY-MM-DD; YYYY-MM, YYYY all acceptable. (With - or / between numbers.)
MIMARKS_v4.xls.zip

[wasade]

Avoiding "/" is ideal as it is a restricted character over URLs. Sticking to an ISO format is beneficial too On Jan 27, 2017 07:23, "Gail Ackermann" <notifications@github.com> wrote: From MIMARKS_v4.xls "The time of sampling, either as an instance (single point in time) or interval. In case no exact time is available, the date/time can be right truncated i.e. all of these are valid times: 2008-01-23T19:23:10+00:00; 2008-01-23T19:23:10; 2008-01-23; 2008-01; 2008; Except: 2008-01; 2008 all are ISO8601 compliant" Although most of our users (I believe) are US based and conform to mm/dd/yyyy where Excel trims to ((m)m/(d)d-yy), confusion arises with non-US users. (As a general rule, users rarely conform to a suggested format.) I am open to suggestion again, but suggest we use the recommendation but not require '2008-01-23T19:23:10+00:00' or '2008-01-23T19:23:10' because no-one will conform to that. Suggest: YYYY-MM-DD HH:MM; YYYY-MM-DD; YYYY-MM, YYYY all acceptable. (With - or / between numbers.) MIMARKS_v4.xls.zip <https://github.com/biocore/qiita/files/735546/MIMARKS_v4.xls.zip> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1885 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAc8smMDhenvkf0Qka9ZyDqOiF6JbRItks5rWgvsgaJpZM4JGzDb> .

[josenavas]

Agree on sticking to a standard. Is a bit frustrating, however, that this was not brought up when it was discussed 8 months ago. There are a fair amount of studies in the DB that will be affected by these and will need to be fixed.

[antgonza]

@wasade and @ackermag, a couple of questions

1. We currently accept the below values, should we simply add the options with - or remove the / and only accept -?

# 4 digits year
'%m/%d/%Y %H:%M:%S', '%m/%d/%Y %H:%M',
'%m/%d/%Y %H', '%m/%d/%Y', '%m/%Y', '%Y',
# 2 digits year
'%m/%d/%y %H:%M:%S', '%m/%d/%y %H:%M',
'%m/%d/%y %H', '%m/%d/%y', '%m/%y', '%y'

2. If we change to only accept -, should we review all current values in the DB and replace dates from / to -?

[wasade]

I think we should use an ISO standard?

…

On Jan 28, 2017 03:54, "Antonio Gonzalez" ***@***.***> wrote: @wasade <https://github.com/wasade> and @ackermag <https://github.com/ackermag>, a couple of questions 1. We currently accept the below values, should we simply add the options with - or remove the / and only accept -? # 4 digits year '%m/%d/%Y %H:%M:%S', '%m/%d/%Y %H:%M', '%m/%d/%Y %H', '%m/%d/%Y', '%m/%Y', '%Y', # 2 digits year '%m/%d/%y %H:%M:%S', '%m/%d/%y %H:%M', '%m/%d/%y %H', '%m/%d/%y', '%m/%y', '%y' 1. If we change to only accept -, should we review all current values in the DB and replace dates from / to -? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1885 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAc8sigLGFN9ZLmqzPl_5p_XFhfIDKg7ks5rWyxigaJpZM4JGzDb> .

[antgonza]

OK, so that means only -, right? What about question 2?

[ackermag]

Q2 - I don't think it is necessary to change all existing in database - there is no consistent way that they are entered. I think submissions to EBI should be ISO standard - I have been doing this despite the warning... I think all you need to do is change the warning... From: sample "10057.245.1", column "collection_timestamp", wrong value "2012-09-21"; or wrong value "Missing: Not reported" To: something else; where 'Missing: Not reported' or any EBI is not "wrong" Gail

…

On Sat, Jan 28, 2017 at 10:53 AM, Antonio Gonzalez ***@***.*** > wrote: OK, so that means only -, right? What about question 2? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1885 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB69gCe3lkbmtcoiDQ2gT6gTcbHWVFZQks5rW46ggaJpZM4JGzDb> .

-- Gail Ackermann Knight Lab UCSD glackermann@ucsd.edu <ackermag@ucsd.edu>

[rob-knight]

Isn't the format specified by mixs? If yes you'd need to bring up proposed changes to Pelin. On Jan 28, 2017, at 1:30 PM, Gail Ackermann <notifications@github.com<mailto:notifications@github.com>> wrote: Q2 - I don't think it is necessary to change all existing in database - there is no consistent way that they are entered. I think submissions to EBI should be ISO standard - I have been doing this despite the warning... I think all you need to do is change the warning... From: sample "10057.245.1", column "collection_timestamp", wrong value "2012-09-21"; or wrong value "Missing: Not reported" To: something else; where 'Missing: Not reported' or any EBI is not "wrong" Gail

…

On Sat, Jan 28, 2017 at 10:53 AM, Antonio Gonzalez ***@***.******@***.***> > wrote: OK, so that means only -, right? What about question 2? - You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1885 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB69gCe3lkbmtcoiDQ2gT6gTcbHWVFZQks5rW46ggaJpZM4JGzDb> .

-- Gail Ackermann Knight Lab UCSD glackermann@ucsd.edu<mailto:glackermann@ucsd.edu> <ackermag@ucsd.edu<mailto:ackermag@ucsd.edu>> - You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#1885 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AB69KVwSpS0VR-kTMH1ofsWvhai0PN1cks5rW7OMgaJpZM4JGzDb>.

[ackermag]

This is MixS: "The time of sampling, either as an instance (single point in time) or interval. In case no exact time is available, the date/time can be right truncated i.e. all of these are valid times: 2008-01-23T19:23:10+00:00; 2008-01-23T19:23:10; 2008-01-23; 2008-01; 2008; Except: 2008-01; 2008 all are ISO8601 compliant" On Sat, Jan 28, 2017 at 1:39 PM, Rob Knight <notifications@github.com> wrote:

…

Isn't the format specified by mixs? If yes you'd need to bring up proposed changes to Pelin. On Jan 28, 2017, at 1:30 PM, Gail Ackermann ***@***.***< ***@***.***>> wrote: Q2 - I don't think it is necessary to change all existing in database - there is no consistent way that they are entered. I think submissions to EBI should be ISO standard - I have been doing this despite the warning... I think all you need to do is change the warning... From: sample "10057.245.1", column "collection_timestamp", wrong value "2012-09-21"; or wrong value "Missing: Not reported" To: something else; where 'Missing: Not reported' or any EBI is not "wrong" Gail On Sat, Jan 28, 2017 at 10:53 AM, Antonio Gonzalez < ***@***.******@***.***> > wrote: > OK, so that means only -, right? What about question 2? > > - > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#1885 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ AB69gCe3lkbmtcoiDQ2gT6gTcbHWVFZQks5rW46ggaJpZM4JGzDb> > . > -- Gail Ackermann Knight Lab UCSD ***@***.******@***.***> ***@***.*** ***@***.***>> - You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://github.com/ qiita-spots/qiita#1885#issuecomment-275875996>, or mute the thread< https://github.com/notifications/unsubscribe-auth/AB69KVwSpS0VR- kTMH1ofsWvhai0PN1cks5rW7OMgaJpZM4JGzDb>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1885 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB69gKRq7F9TBcZ6JV77jYPqxtloSnvKks5rW7WVgaJpZM4JGzDb> .

-- Gail Ackermann Knight Lab UCSD glackermann@ucsd.edu <ackermag@ucsd.edu>

[antgonza]

Closed by #2075