set created and updatedat to epoch

[Alphatiger]

when timestamps options is true, there should be an option to set the timestamp to epoch, instead of only ISO string

[clarkie]

Hi @Alphatiger, thanks for the suggestion but can you explain what problem you have storing them as ISO strings? Thanks, Clarkie

[Alphatiger]

when backends doesn't support date operations e.g dynamodb we can fall back to epoch based comparison.

[clarkie]

I've always found the 2018-01-03 format much better as often people ask for reports between two dates and it's much easier to reason about date >= '2017-12-01' && date <= '2017-12-31' than using timestamps date >= 1512086400 && date <= 1514678400

[Alphatiger]

As i mentioned above the dynamodb doesnt allow any date operations, we have to fallback to epoch for this purpose, so ideally give an option for timestamp to be epoch or ISO string. this should be an option available at table declaration itself

[clarkie]

But dynamodb doesn't need any date operations. You can use string operations for the comparisons as I showed above.

[Alphatiger]

Hi Thanks

my primary tested showed this is working, can you please tell me does dynamodb compare this as per their ascii values or how it compares?

[cdhowie]

The comparison is lexicographic. One of the advantages of ISO-8601-formatted dates is that they can be compared lexicographically, since more significant date components always appear to the left of less significant date components.

[clarkie]

@Alphatiger yes, dynamodb does compare using ascii values:

String value comparisons for greater than, equals, or less than are based on ASCII character code values. For example, a is greater than A, and a is greater than B. For a list of code values, see http://en.wikipedia.org/wiki/ASCII#ASCII_printable_characters.

https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html

I'm closing this as I think we have resolved your issue.

Thanks, Clarkie