search

cuizhennan / snakeyaml

Automatically exported from code.google.com/p/snakeyaml
Apache License 2.0
1 stars 0 forks source link

Feature request: Specify default timezone for parser / dumper #141

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
It would be nice to specify default time zone for the parser so when there is 
no timezone specified in YAML default timezone is used, not just UTC.

Similar for dumper. Dump all timestamps in default timezone, not just UTC.

Original issue reported on code.google.com by yaro...@gmail.com on 3 Feb 2012 at 7:43

GoogleCodeExporter commented 9 years ago 
1) The parser may not use any time zone because it contradicts with the YAML 
specification: http://yaml.org/type/timestamp.html
"If the time zone is omitted, the timestamp is assumed to be specified in UTC."
But if you want to use your time zone, you can extend SnakeYAML and provide 
your own way to parse dates. Check an example with JodaTime: 
http://code.google.com/p/snakeyaml/source/browse/#hg%2Fsrc%2Ftest%2Fjava%2Fexamp
les%2Fjodatime

2) No problem to introduce time zone for dumper. Check the source and the 
latest 1.10-SNAPSHOT

http://code.google.com/p/snakeyaml/source/browse/src/test/java/org/yaml/snakeyam
l/issues/issue141/ConfigurableTimezoneTest.java

Original comment by py4fun@gmail.com on 3 Feb 2012 at 11:38

GoogleCodeExporter commented 9 years ago 
"If the time zone is omitted, the timestamp is assumed to be specified in UTC."

Quite a weird requirement for the markup language that positions itself to be 
human-editable. But OK. Spec is spec.

Thanks for the directions anyway! I am going to violate the spec right now, 
cause I'm human :)

Original comment by yaro...@gmail.com on 3 Feb 2012 at 1:23

GoogleCodeExporter commented 9 years ago 
You do not violate the spec if you parse the YAML document in your own way. 
This is how it should be and that is why SnakeYAML tries to be as flexible as 
possible. But you cannot ask from a general-purpose tool to behave in your 
specific way because other users may have different expectations. These 
expectations are frozen in a spec. When the limitation are known and agreed all 
the deviations are under control.

(By the way my expectation is that without the time zone it must be UTC. 
Otherwise the very same document parsed in different places gets different 
dates.)

Does it work for you ? Can I close the issue ?

Original comment by py4fun@gmail.com on 3 Feb 2012 at 1:37

GoogleCodeExporter commented 9 years ago 
Yes, you can close the issue. Thanks again for the help!

(If the document is meant to travel the world it should specify timezones 
explicitly. That's for sure. On the other hand it is common practice to 
interpret dates and times without specified timezone relative to local time. I 
can't even recall any other tool that falls back to UTC for that purpose. 
That's why I think it is weird. Especially for the data being filled in by 
human, not dumped by software. But spec is spec. Your tool is great!)

Original comment by yaro...@gmail.com on 3 Feb 2012 at 2:59

GoogleCodeExporter commented 9 years ago 
It will be available in version 1.10

Original comment by py4fun@gmail.com on 3 Feb 2012 at 3:42