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 -?