summaryrefslogtreecommitdiff
path: root/src/Hakyll.hs
diff options
context:
space:
mode:
authorJorge Israel Peña <jorge.israel.p@gmail.com>2014-05-09 02:11:56 -0700
committerJorge Israel Peña <jorge.israel.p@gmail.com>2014-05-09 02:11:56 -0700
commitd86b4753d4811a0f1bd1004e83296238c83a383a (patch)
tree9896ca0c58d9f89e62d2eda2cf47c498694d281f /src/Hakyll.hs
parent43c2aeae54253157725c6a58318fff9f2776f108 (diff)
downloadhakyll-d86b4753d4811a0f1bd1004e83296238c83a383a.tar.gz
save modification time with sub-second granularity
Some systems can get the file modification time with sub-second granularity. However, Hakyll shaves off the sub-seconds, as defined in the Binary instance of BinaryTime, which poses a problem because when a file is checked to see if it was modified in `resourceModified`, it still contains the sub-seconds. This results in a file (almost) always being considered as having been modified. Example: 1. First go around, modification time is 3:45.325. This time is saved as 3:45.000 (i.e. sub-seconds are shaved off). 2. Second go around, modification time is again read as 3:45.325 and compared against the stored time, 3:45.000. 3:45.325 is more recent than 3:45.000, so the file is considered to have been modified. This change prevents the shaving off of sub-seconds. This will naturally work on systems that don't support sub-second granularity, as that 'field' will simply appear as all zeros. Closes #250
Diffstat (limited to 'src/Hakyll.hs')
0 files changed, 0 insertions, 0 deletions