Hello,
An enterprise geodatabase reader interprets a value in a date field as: 20130426000000
A file geodatabase reader interprets the same date value as: 20130426
This is a problem when comparing date values in ChangeDetector, as they are always noted as an update, even though they are essentially the same value.
Does anyone have any ideas on how to make the 2 dates comparable?
Best answer by sparki
Thanks for the suggestion.
In the end I did something similar. Rather than concatenate zeros I stripped them from the enterprise geodatabase values.
To do this I used a combination of AttributeValidator and ExpressionEvaluator.
AttributeValidator is used to test any date fields for 6 trailing zeros using regex: [0+]{6}$
ExpressionEvaluator is used to remove the trailing zeros: @CurrentAttribute() * 0.000001 (overwrite existing attribute)
The easy way out is to simply concatenate "000000" at the end of all the date values coming from the File Geodatabase, before doing the comparison.
Thanks for the suggestion.
In the end I did something similar. Rather than concatenate zeros I stripped them from the enterprise geodatabase values.
To do this I used a combination of AttributeValidator and ExpressionEvaluator.
AttributeValidator is used to test any date fields for 6 trailing zeros using regex: [0+]{6}$
ExpressionEvaluator is used to remove the trailing zeros: @CurrentAttribute() * 0.000001 (overwrite existing attribute)
Thanks for the suggestion.
In the end I did something similar. Rather than concatenate zeros I stripped them from the enterprise geodatabase values.
To do this I used a combination of AttributeValidator and ExpressionEvaluator.
AttributeValidator is used to test any date fields for 6 trailing zeros using regex: [0+]{6}$
ExpressionEvaluator is used to remove the trailing zeros: @CurrentAttribute() * 0.000001 (overwrite existing attribute)
That's of course going to work as well. Although it might be a little bit slower*, since the operations are more complex. Also, just be sure that your division isn't introducing tiny rounding errors that trips up your change detection.
(*slower, as in, you'll probably only notice it for very large datasets with time-critical operations)
+10I think your best way would be to use a DateTimeFormatter on the data from the enterprise geodatabase. If you use FME Auto Detect it will set your date accordingly. The standard format that FME reads dates is YYYYmmddHHMMSS YYYY = Year, mm = Month, dd = Day, HH = Hour, MM = Minute, SS Second. There are several output formats but FME Date would change your date to equal 20130426.
Additionally, you can specify different formats for dates by manually typing in info. For example if you want the dates to be 04/26/2013, you could set the output format as %m/%d/%Y.
The standard output format characters are %Y = YYYY (Year), %m = mm (Month), %d = dd(Day), %H = HH (Hour), %M = MM (Minute), %S = SS (Second). As long as these characters are in the output, the format can be manipulated in many ways.
