Skip to main content
SharePoint

Return to Answer

Added a section describing why I chose my own solution.
Source Link
Chris Jaynes
Chris Jaynes
  • 193
  • 1
  • 1
  • 9

Rather than arguing with SharePoint about date formats, which was proving to be quite a tedious dicsussion, I ended up mirroring the Created date into a calculated Timestamp field that's configured like this:

=TEXT(Created,"yyyy-mm-ddThh:mm:ss")

This Timestamp column ends up being a string value that's easier to deal with on pretty much all levels.

I don't know if the datetime format in Per Jakobsen's answer would work, but I'd rather not muck up those already UGLY SP urls any worse than I have to.

EDIT: As discussed in the comments on the other answers, and after attempting those solutions, I've determined that it's not a good idea for SP to be sending the date down in the ASP.Net format, but then requires us to compare dates using the ISO format. This solution allows the ISO format to be used both ways, and eliminated issues I was having with the Time Zones not parsing back and forth properly across formats.

Thanks to the other folks who provided potential solutions. Hopefully this discussion will be of use to others.

Rather than arguing with SharePoint about date formats, which was proving to be quite a tedious dicsussion, I ended up mirroring the Created date into a calculated Timestamp field that's configured like this:

=TEXT(Created,"yyyy-mm-ddThh:mm:ss")

This Timestamp column ends up being a string value that's easier to deal with on pretty much all levels.

I don't know if the datetime format in Per Jakobsen's answer would work, but I'd rather not muck up those already UGLY SP urls any worse than I have to.

Rather than arguing with SharePoint about date formats, which was proving to be quite a tedious dicsussion, I ended up mirroring the Created date into a calculated Timestamp field that's configured like this:

=TEXT(Created,"yyyy-mm-ddThh:mm:ss")

This Timestamp column ends up being a string value that's easier to deal with on pretty much all levels.

I don't know if the datetime format in Per Jakobsen's answer would work, but I'd rather not muck up those already UGLY SP urls any worse than I have to.

EDIT: As discussed in the comments on the other answers, and after attempting those solutions, I've determined that it's not a good idea for SP to be sending the date down in the ASP.Net format, but then requires us to compare dates using the ISO format. This solution allows the ISO format to be used both ways, and eliminated issues I was having with the Time Zones not parsing back and forth properly across formats.

Thanks to the other folks who provided potential solutions. Hopefully this discussion will be of use to others.

edited body
Source Link
Chris Jaynes
Chris Jaynes
  • 193
  • 1
  • 1
  • 9

Rather than arguing with SharePoint about date formats, which was proving to be quite a tedious dicsussion, I ended up mirroring the Created date into a calculated Timestamp field that's configured like this:

=TEXT(Created,"yyyy-mm-dd:hhddThh:mm:ss")

This Timestamp column ends up being a string value that's easier to deal with on pretty much all levels.

I don't know if the datetime format in Per Jakobsen's answer would work, but I'd rather not muck up those already UGLY SP urls any worse than I have to.

Rather than arguing with SharePoint about date formats, which was proving to be quite a tedious dicsussion, I ended up mirroring the Created date into a calculated Timestamp field that's configured like this:

=TEXT(Created,"yyyy-mm-dd:hh:mm:ss")

This Timestamp column ends up being a string value that's easier to deal with on pretty much all levels.

I don't know if the datetime format in Per Jakobsen's answer would work, but I'd rather not muck up those already UGLY SP urls any worse than I have to.

Rather than arguing with SharePoint about date formats, which was proving to be quite a tedious dicsussion, I ended up mirroring the Created date into a calculated Timestamp field that's configured like this:

=TEXT(Created,"yyyy-mm-ddThh:mm:ss")

This Timestamp column ends up being a string value that's easier to deal with on pretty much all levels.

I don't know if the datetime format in Per Jakobsen's answer would work, but I'd rather not muck up those already UGLY SP urls any worse than I have to.

Source Link
Chris Jaynes
Chris Jaynes
  • 193
  • 1
  • 1
  • 9

Rather than arguing with SharePoint about date formats, which was proving to be quite a tedious dicsussion, I ended up mirroring the Created date into a calculated Timestamp field that's configured like this:

=TEXT(Created,"yyyy-mm-dd:hh:mm:ss")

This Timestamp column ends up being a string value that's easier to deal with on pretty much all levels.

I don't know if the datetime format in Per Jakobsen's answer would work, but I'd rather not muck up those already UGLY SP urls any worse than I have to.